PIMVI (2)

Prévia do material em texto

UNIVERSIDADE PAULISTA - UNIP EaD
Projeto Integrado Multidisciplinar
Curso Superior de Tecnologia em
Análise e Desenvolvimento de Sistemas
MÁRIO SÉRGIO LIMA CRAVEIRO - 2283999
MEZZOFANI PEREIRA DE OLIVEIRA - 0612201
LEVANTAMENTO DE REQUISITOS:
ESTUDO DE CASO DA EMPRESA GEEK LTDA
PICUÍ-PB
2023
RESUMO
Este trabalho busca concluir a etapa referente ao “Levantamento de Requisitos”
dentro do projeto de desenvolvimento de software para a empresa GEEK LTDA. Assim,
utiliza-se a Unified Modeling Language (UML) para construir diagramas com o intuito de
facilitar o entendimento dos requisitos identificados, como por exemplo: diagrama de
processos, diagrama de casos de uso e, até mesmo, o modelo conceitual de banco de
dados entre entidades e relacionamentos (MER). Para isto, usa-se dois softwares:
StarUML, para os diagramas de caso de uso, de processo e classes de análise e o
BrModelo, para a construção do MER. Neste sentido, verifica-se as regras do negócio
para ir além dos requisitos funcionais e alcançar os requisitos não funcionais (RNF),
principalmente a acessibilidade, segurança e operacionalidade.
Palavras-chave: UML. MER. Levantamento de Requisitos. GEEK LTDA. Requisitos
Não-Funcionais. StarUML. BrModelo.
ABSTRACT
This work seeks to conclude the stage referring to the "Requirements Gathering"
within the software development project for the company GEEK LTDA. Thus, the Unified
Modeling Language (UML) is used to build diagrams in order to facilitate the
understanding of the identified requirements, such as: process diagram, use case diagram
and even the conceptual model of a database. data between entities and relationships
(MER). For this, two softwares are used: StarUML, for the use case, process and analysis
class diagrams and BrModelo, for the construction of the MER. In this sense, the business
rules are verified to go beyond the functional requirements and reach the non-functional
requirements (RNF), mainly accessibility, security and operability.
Keywords: UML. MER. Requirements gathering. GEEK LTD. Non-Functional
Requirements. StarUML. BrModel.
SUMÁRIO
1. 1.0 INTRODUÇÃO…………………………………………………………………………5
2. 2.0 CENÁRIO E CONTEXTO HIPOTÉTICOS………………………………………….6
3. 3.0 FUNÇÕES E REGRAS DE NEGÓCIO….………………………………………….6
4. 4.0 PROCESSOS DE NEGÓCIO…………………………………………………..…….7
5. 5.0 ATIVIDADES AUTOMATIZADAS…..………………………………………………..9
6. 6.0 MODELAGEM DE CASOS DE USO….…………………………………………….9
7. 7.0 REQUISITOS NÃO FUNCIONAIS (RNF)………………………………………….20
8. 6.0 DIAGRAMA DE CLASSES DE ANÁLISE………………………………………….21
9. 7.0 MODELO DE DADOS (MER).……………………………………………………...22
10. 9.0 CONCLUSÃO………………………………………………………………………..23
11. 10.0 REFERÊNCIAS…………………………………………………………………….24
5
1.0 INTRODUÇÃO
A inovação tecnológica é, ao mesmo tempo, o motivo e a força motriz para
adaptação das empresas às novas necessidades do mercado. Desta forma, a empresa
GEEK LTDA percebeu a indispensabilidade de um novo sistema para Controle de
Estoques e Gestão de Vendas. Neste sentido, ao contratar uma empresa para a
elaboração deste software, a organização se depara com a fase de Levantamento de
Requisitos.
Para isso, utiliza-se a Engenharia de Requisitos, uma importante integrante da
Engenharia de Software e da Análise de Sistema, assim como a Análise de Negócios.
Nesta engenharia, é preciso que exista a descrição dos requisitos e sua classificação em
funcionais e não funcionais, com o objetivo de auxiliar a produção lógica, validar os
requisitos com a GEEK LTDA e, principalmente, construir o mapa para o desenvolvimento
do software.
6
2.0 CENÁRIO E CONTEXTO HIPOTÉTICOS
A empresa hipotética conhecida como GEEK LTDA possui como atividade principal
a venda no varejo de mercadorias geeks, eletrônicos e acessórios. Sendo assim, por
possuir um alto fluxo de produtos, faz-se necessário o uso de um sistema para controle e
gerenciamento de vendas. Contudo, a atual forma de controle, baseada em um sistema
de Excel, não consegue mais ser eficiente enquanto ferramenta de gestão. Dessa
maneira, a organização fechou o contrato com uma fábrica de software para solucionar
essa demanda.
Assim, esta pesquisa baseia-se neste caso hipotético, especialmente na etapa em
que a GEEK LTDA solicita um levantamento de requisitos e pede para que o sistema
desenvolvido para desktop possua módulos de acessibilidade, pois eventuais usuários
portadores de deficiência irão conseguir utilizá-lo.
3.0 FUNÇÕES E REGRAS DE NEGÓCIO
O processo de Levantamento de requisitos possui como ponto de partida a
identificação das funções de negócio que, de maneira breve e sucinta, podem ser
entendidas como a conexão entre o que a organização faz, como faz e por meio de quem
os processos são feitos (PLAIS, 2016). Neste sentido, ao analisar o sistema de controle
de estoques e vendas da GEEK LTDA, percebe-se as seguintes funções:
I. Controle de Estoque: função que refere-se aos processos inerentes ao
controle de estoque, gestão de inventário e atividades similares;
II. Gestão de Vendas: função que agrupa processos diretamente
relacionados às vendas;
III. Banco de Dados: o sistema deve reunir os principais dados de produtos
e clientes da empresa.
Assim, com as funções essenciais descritas, torna-se natural que se busque as
regras do negócio. Em outras palavras, o próximo passo para o levantamento de
requisitos é o detalhamento das restrições e os limites a serem respeitados e, ao mesmo
tempo, executados. Desta forma, a partir da observação do cenário hipotético,
constata-se as regras de negócio dispostas na tabela abaixo:
7
Tabela 01 - Regras de Negócio
REGRAS DE NEGÓCIO
1. Quanto ao acesso geral:
a) Todo e qualquer acesso no sistema deve ser feito na loja e acompanhado de um
login e de uma senha;
2. Quanto ao estoque:
a) Os produtos cadastrados no estoque
só poderão assumir uma das seguintes
naturezas: acessórios, produtos geeks e
jogos;
b)Todos os produtos devem possuir:
código de barras, nome do produto,
categoria, fabricante, quantidade e valor
do produto. Para os jogos e acessórios,
devem ser informados em qual plataforma
serão utilizados e qual o prazo de garantia
que o produto possui;
3. Quanto ao cadastro de clientes:
a) Os cadastros dos clientes devem possuir: código, RG, CPF, nome, data do cadastro,
endereço, telefone e e-mail do cliente;
4. Quanto a venda:
a) A venda deverá possuir os dados do
cliente e todos os produtos adquiridos.
Deve ser gerado um código único da
venda, com a data da venda, o valor da
venda, opções para pagamento
(dinheiro/cartão), status de pagamento e
status da venda;
b) O atendente poderá consultar os preços
dos produtos caso o cliente solicite;
5. Quanto ao cancelamento e a exclusão:
a) Apenas o supervisor da loja poderá
excluir o produto da venda, devendo
informar um usuário e senha válidos;
b)A venda pode ser cancelada apenas
pelo supervisor da loja, que deve informar
usuário e senha válidos. No momento do
cancelamento, o código da venda deve ser
enviado para o sistema financeiro.
Fonte: Próprio autor
4.0 PROCESSOS DE NEGÓCIO
Cada uma das funções de negócio são compostas por processos que as definem e
que as moldam. Neste sentido, através da linguagem UML (Unified Modeling Language) e
8
com auxílio do software StarUML desenvolvido pelo MKLab, cria-se diagramas de
processos, também conhecidos como diagramas Eriksson‑Penker, para cada função.
Contudo, é importante salientar que, por ser uma extensão da linguagem UML tradicional,
o diagrama Eriksson-Penker não é um dos modelos padrões presentes no StarUML,
muito embora, é possível adaptar o fluxograma identificando os elementos através de
estereótipos que podem ser exemplificados dessa forma: <<estereótipo>> .
Figura 01: Diagrama de Processos
9
Fonte: Próprio Autor
Na Figura 01, percebe-se que as funções “Banco de Dados” e “Controle de
Estoque” dividem espaço, ou seja, processos de negócio podem pertencer a uma ou mais
funções. Além disso, nota-se que os processos presentes são: Manutenção de Estoque,Armazenamento e Manutenção de dados, Manutenção de Cadastro e, por fim, Venda de
produtos.
5.0 ATIVIDADES AUTOMATIZADAS
Quando se entende os processos de negócio, cria-se uma facilidade para
identificar as atividades que deverão ser automatizadas. No caso desta pesquisa, serão:
a) em Armazenamento e Manutenção de dados: controle de permissões e níveis
de acesso, Login e Logout de usuários e manutenção de status de dados de
venda, de produto, de cliente e de funcionário;
b) Manutenção de Estoque: cadastramento e exclusão de produtos, gestão do
fluxo de produtos, solicitar novos produtos;
c) Manutenção de Cadastro: cadastramento e alteração de dados de clientes,
atualização do histórico de cliente;
d) Vendas de produtos: cadastramento e cancelamento de vendas, soma de
valores adicionados a venda.
6.0 MODELAGEM DE CASOS DE USO
A partir da identificação das atividades que serão automatizadas no sistema, é
possível realizar a modelagem de casos de uso que, segundo Bezerra (2006, p. 45),
trata-se de “uma representação das funcionalidades externamente observáveis do
sistema e dos elementos externos ao sistema que interagem com ele”. Diante disso,
sabe-se que o processo de modelagem é composto por duas etapas: I. identificação e
descrição dos casos de uso; II. construção do diagrama de casos de uso.
Neste sentido, e visando o cumprimento da primeira etapa, elabora-se uma tabela
para cada caso de uso com seus principais componentes, conforme observado abaixo:
10
.Tabela 02: Caso I
Caso 01: Fazer Login
Elementos: Descrição:
Escopo Interface de login do sistema.
Propósito Esse caso de uso permite ao autor realizar o login no sistema e,
dependendo das suas permissões, acessar determinadas
funcionalidades.
Ator Primário Funcionários(estoquista, supervisor e atendente).
Pré-condições O funcionário e suas credenciais(login,senha e permissões) devem
estar cadastrados no sistema. O sistema deve estar operacional.
Pós-condições Ao efetuar o login, o sistema reconhece as permissões do
funcionário, podendo liberar ou bloquear determinadas
funcionalidades.
Fluxo normal O funcionário insere o seu login e depois a sua senha. O sistema
reconhece as credenciais e direciona o usuário para a interface das
funcionalidades.
Fluxo alternativo a) Caso o usuário não preencha qualquer uma das credenciais,
uma mensagem é exibida;
b) Caso o usuário preencha a senha incorretamente, uma
mensagem é exibida. Se as próximas duas tentativas
também forem com senhas incorretas, outra mensagem é
exibida e o acesso será bloqueado;
c) Caso o sistema não identifique o login no banco de dados,
uma mensagem para o sistema de cadastro de usuário é
exibida.
Fonte: Próprio autor
.Tabela 03: Caso II
Caso 02: Cadastro de Produto
Elementos: Descrição:
Escopo Interface de cadastro de produto
Propósito Esse caso de uso permite ao autor realizar o cadastro de novos
produtos no sistema
Ator Primário Estoquista
11
Pré-condições O funcionário deve possuir a permissão de estoquista para
conseguir cadastrar um novo produto.
Pós-condições Ao realizar o cadastro do novo produto, o sistema o insere no
inventário
Fluxo normal O funcionário insere o seu login e depois a sua senha. O sistema
reconhece as credenciais e direciona o estoquista para a interface
das funcionalidades. O estoquista acessa a funcionalidade de
cadastrar novos produtos. O estoquista insere todos os atributos do
produto no sistema e finaliza o cadastro. O sistema exibe uma
mensagem de produto cadastrado.
Fluxo alternativo a) Caso o estoquista não preencha qualquer um dos atributos
obrigatórios e tente prosseguir para finalizar o cadastro, o
sistema não permite e exibe uma mensagem.
Fonte: Próprio autor
.Tabela 04: Caso III
Caso 03: Alterar atributos
Elementos: Descrição:
Escopo Interface de cadastro de produto
Propósito Esse caso de uso permite ao autor alterar os atributos de um
determinado produto.
Ator Primário Estoquista
Pré-condições O funcionário deve possuir a permissão de estoquista para
conseguir alterar um produto.
Pós-condições Ao realizar a mudança, o sistema deve atualizar os dados
instantaneamente no inventário.
Fluxo normal O funcionário insere o seu login e depois a sua senha. O sistema
reconhece as credenciais e direciona o estoquista para a interface
das funcionalidades. O estoquista acessa a funcionalidade de
alterar produtos, altera os dados e finaliza mudança. O sistema
exibe uma mensagem e atualiza os atributos.
Fluxo alternativo a) Cadastrar um novo produto acessa automaticamente esta
função;
b) Caso o estoquista exclua um atributo obrigatório e não o
preencha novamente com novos dados antes de tentar
finalizar a mudança, o sistema exibe uma mensagem e não
12
permite as alterações.
Fonte: Próprio autor
.Tabela 05: Caso IV
Caso 04: Excluir Produto do inventário
Elementos: Descrição:
Escopo Interface de inventário
Propósito Esse caso de uso permite ao autor excluir produtos do inventário.
Ator Primário Estoquista
Pré-condições O funcionário deve possuir a permissão de estoquista para
conseguir excluir um produto do inventário.
Pós-condições Ao realizar a exclusão, o sistema deve atualizar o inventário e
excluir o determinado produto do banco de dados.
Fluxo normal O funcionário insere o seu login e depois a sua senha. O sistema
reconhece as credenciais e direciona o estoquista para a interface
das funcionalidades. O estoquista acessa a funcionalidade de
excluir produtos e seleciona o produto desejado para exclusão. O
sistema exibe uma mensagem e atualiza o inventário.
Fluxo alternativo a) Caso o estoquista tente excluir um produto com status “em
venda”, o sistema exibirá uma mensagem e não permitirá a
exclusão.
b) Este caso de uso é automaticamente acessado quando o
estoquista acessa o caso conhecido como: “Agendar
Exclusão”
Fonte: Próprio autor
.Tabela 06: Caso V
Caso 05: Agendar exclusão
Elementos: Descrição:
Escopo Interface de inventário
Propósito Esse caso de uso permite ao autor agendar a exclusão de produtos
do inventário.
Ator Primário Estoquista
Pré-condições O funcionário deve possuir a permissão de estoquista para
13
conseguir agendar a exclusão de um produto do inventário.
Pós-condições Ao realizar o agendamento de exclusão, o sistema deve atualizar o
status de um determinado produto para: "exclusão agendada”
Fluxo normal O funcionário insere o seu login e depois a sua senha. O sistema
reconhece as credenciais e direciona o estoquista para a interface
das funcionalidades. O estoquista acessa a funcionalidade de
agendar exclusão e seleciona o produto desejado. O sistema exibe
uma mensagem e atualiza o status do produto.
Fluxo alternativo a) Caso o estoquista tente agendar a exclusão de um produto
com status “em venda”, o sistema exibirá uma mensagem e
não permitirá o agendamento..
Fonte: Próprio autor
Tabela 07: Caso VI
Caso 06: Solicitar um novo produto
Elementos: Descrição:
Escopo Interface de inventário
Propósito Esse caso de uso permite ao autor solicitar um novo produto para
compor o inventário.
Ator Primário Estoquista.
Pré-condições O funcionário deve possuir a permissão de estoquista para
conseguir solicitar um novo produto.
Pós-condições Ao solicitar um novo produto, o sistema deve adicionar o produto no
inventário com o status de “pedido solicitado"
Fluxo normal O funcionário insere o seu login e depois a sua senha. O sistema
reconhece as credenciais e direciona o estoquista para a interface
das funcionalidades. O estoquista acessa a funcionalidade de
solicitar novo produto e preenche os atributos do produto que deseja
solicitar ou seleciona um produto existente no banco de dados. O
sistema exibe uma mensagem e redireciona o pedido para o setor
financeiro da empresa.
Fluxo alternativo a) Esta funcionalidade pode ser acessada após a exclusão de
um produto.
Fonte: Próprio autor
14
Com o intuito de favorecer o entendimento, preferiu-se dividir o diagrama de casos
de usos em dois ambientes: Vendas e Estoque. Assim, como já foram apresentados todos
oscasos relacionados ao ambiente estoque, segue o diagrama de casos de uso deste
ambiente para que sejam identificadas as relações de include, extend e generalização.
Figura 02: Diagrama de Casos de Uso - Estoque
Fonte: Próprio autor
Tabela 08: Caso VII
Caso 07: Cadastrar cliente
Elementos: Descrição:
Escopo Interface de cadastro de cliente
Propósito Esse caso de uso permite ao autor cadastrar um cliente
Ator Primário Supervisor e Atendente
Pré-condições O funcionário deve possuir a permissão de atendente ou supervisor
para conseguir cadastrar um cliente.
Pós-condições Ao cadastrar um novo cliente, o sistema deverá inserir o novo
cliente no banco de dados
Fluxo normal O funcionário insere o seu login e depois a sua senha. O sistema
reconhece as credenciais e direciona o funcionário para a interface
das funcionalidades. O funcionário acessa a funcionalidade
referente a cadastrar um novo cliente, preenche os atributos do
15
cliente e finaliza o cadastro O sistema exibe uma mensagem e
atualiza o banco de dados
Fluxo alternativo a) Caso o funcionário não preencha todos os atributos
obrigatórios e tente finalizar o cadastro, o sistema exibe uma
mensagem e não permite o cadastramento;
b) Caso um dos atributos já pertença a um cliente cadastrado, o
sistema exibe uma mensagem e não permite a finalização.
Fonte: Próprio autor
Tabela 09: Caso VIII
Caso 08: Alterar atributo de cliente
Elementos: Descrição:
Escopo Interface de cadastro de cliente
Propósito Esse caso de uso permite ao autor modificar o cadastro de um
cliente
Ator Primário Supervisor e Atendente
Pré-condições O funcionário deve possuir a permissão de atendente ou supervisor
para conseguir modificar o cadastro de um cliente.
Pós-condições Ao modificar um novo cadastro, o sistema deverá atualizar os
atributos do cliente no banco de dados
Fluxo normal O funcionário insere o seu login e depois a sua senha. O sistema
reconhece as credenciais e direciona o funcionário para a interface
das funcionalidades. O funcionário acessa a funcionalidade
referente a modificar cadastro, preenche ou altera os atributos do
cliente e finaliza a modificação O sistema exibe uma mensagem e
atualiza o banco de dados
Fluxo alternativo a) Caso o funcionário exclua um dos atributos obrigatórios e
insira novos dados, o sistema exibe uma mensagem e não
permite a modificação;
b) Caso um dos atributos já pertença a um cliente cadastrado, o
sistema exibe uma mensagem e não permite a finalização;
c) Esse caso de uso pode ser executado facilmente após o caso
de uso “Acessar cadastro do cliente”.
Fonte: Próprio autor
Tabela 10: Caso IX
Caso 09: Acessar cadastro do cliente
16
Elementos: Descrição:
Escopo Interface de cadastro de cliente
Propósito Esse caso de uso permite ao autor acessar o cadastro de um cliente
e verificar seus dados.
Ator Primário Supervisor e Atendente
Pré-condições O funcionário deve possuir a permissão de atendente ou supervisor
para conseguir acessar o cadastro de um cliente.
Pós-condições Ao acessar um cadastro, o usuário deve conseguir visualizar todos
os dados cadastrados de um cliente.
Fluxo normal O funcionário insere o seu login e depois a sua senha. O sistema
reconhece as credenciais e direciona o funcionário para a interface
das funcionalidades. O funcionário acessa a funcionalidade
referente a acessar cadastro. O sistema exibe os dados do cliente.
Fluxo alternativo Não possui fluxo alternativo
Fonte: Próprio autor
Tabela 11: Caso X
Caso 10: Adicionar Produtos na Venda
Elementos: Descrição:
Escopo Interface de Venda
Propósito Esse caso de uso permite ao autor adicionar determinados produtos
na venda.
Ator Primário Supervisor e Atendente
Pré-condições O funcionário deve possuir a permissão de atendente ou supervisor
para conseguir adicionar produtos na venda. A venda só acontece
caso um cliente já cadastrado esteja selecionado.
Pós-condições Ao adicionar um produto na venda, o sistema deve, ao mesmo
tempo, somar o valor dos produtos como pré inseri-los no cupom
fiscal.
Fluxo normal O funcionário insere o seu login e depois a sua senha. O sistema
reconhece as credenciais e direciona o funcionário para a interface
das funcionalidades. O funcionário acessa a funcionalidade
referente a adicionar produtos e seleciona os produtos que serão
adicionados.
Fluxo alternativo a) Esta funcionalidade pode ser acessada após o caso de uso
17
“Cadastrar Cliente”, em uma relação de extensão;
b) Caso o funcionário adicione um produto não cadastrado no
inventário, o sistema exibe uma mensagem de erro;
Fonte: Próprio autor
Tabela 12: Caso XI
Caso 11: Finalizar Venda
Elementos: Descrição:
Escopo Interface de Venda
Propósito Esse caso de uso permite ao autor finalizar a venda.
Ator Primário Supervisor e Atendente
Pré-condições O funcionário deve possuir a permissão de atendente ou supervisor
para conseguir finalizar a venda. A venda só pode ser finalizada
caso haja produtos adicionados.
Pós-condições Ao finalizar a venda, o sistema deve diminuir a quantidade de um
determinado produto no estoque, adicionar à venda no fluxo diário
e, também, no histórico de compras do cliente.
Fluxo normal O funcionário insere o seu login e depois a sua senha. O sistema
reconhece as credenciais e direciona o funcionário para a interface
das funcionalidades. O funcionário acessa a funcionalidade de
finalizar a venda após ter os produtos adicionados. O sistema
executa as vendas e as pós-condições
Fluxo alternativo a) Esta funcionalidade pode ser acessada após o caso de uso
"Adicionar produtos na venda”
Fonte: Próprio autor
Tabela 13: Caso XII
Caso 12: Definir forma de pagamento
Elementos: Descrição:
Escopo Interface de Venda
Propósito Esse caso de uso permite ao autor definir a forma de pagamento da
venda.
Ator Primário Supervisor e Atendente
Pré-condições O funcionário deve possuir a permissão de atendente ou supervisor
para conseguir definir a forma de pagamento. A função finalizar a
18
venda deve ter sido executada.
Pós-condições Ao definir a forma de pagamento, o sistema deve calcular se o valor
final terá inferências.
Fluxo normal O funcionário insere o seu login e depois a sua senha. O sistema
reconhece as credenciais e direciona o funcionário para a interface
das funcionalidades. O funcionário acessa a funcionalidade de
finalizar a venda. O sistema exibe a tela para escolher a forma de
pagamento. O funcionário seleciona a forma de pagamento. O
sistema exibe uma mensagem
Fluxo alternativo a) Caso o usuário não selecione nenhuma forma de pagamento
e tente prosseguir, o sistema deve exibir uma mensagem e
não permitir o prosseguimento.
Fonte: Próprio autor
Tabela 14: Caso XIII
Caso 13: Gerar Cupom Fiscal
Elementos: Descrição:
Escopo Interface de Venda
Propósito Esse caso de uso permite ao autor gerar o cupom fiscal da venda
Ator Primário Supervisor e Atendente
Pré-condições O funcionário deve possuir a permissão de atendente ou supervisor
para conseguir gerar o cupom fiscal. É necessário que produtos já
tenham sido adicionados à venda e a forma de pagamento já tenha
sido escolhida.
Pós-condições Ao gerar o cupom fiscal, o sistema deve repassar suas informações
para o histórico de compras do cliente.
Fluxo normal O funcionário insere o seu login e depois a sua senha. O sistema
reconhece as credenciais e direciona o funcionário para a interface
das funcionalidades. O funcionário acessa a funcionalidade de
finalizar a venda. O sistema exibe a tela para escolher a forma de
pagamento. Após isso, o funcionário acessa a funcionalidade de
gerar o cupom fiscal. O sistema emite o cupom para salvamento ou
impressão.
Fluxo alternativo a) Caso o usuário não gere o cupom fiscal, o sistema emite uma
mensagem e não permite que o caso de uso “Finalizar
Venda" conclua.
Fonte: Próprio autor
19
Tabela 15: Caso XIV
Caso 14: Alterar Status do Produto
Elementos: Descrição:
Escopo Interface de Venda
Propósito Esse caso de uso permite ao autor alterar o status de um produto
Ator Primário Supervisor e Atendente
Pré-condiçõesO funcionário deve possuir a permissão de atendente ou supervisor
para conseguir gerar alterar o status do produto.
Pós-condições As classes Supervisor e Atendente só podem alterar o status de um
produto para: “em venda” e “vendido”
Fluxo normal O funcionário insere o seu login e depois a sua senha. O sistema
reconhece as credenciais e direciona o funcionário para a interface
das funcionalidades. O funcionário acessa a funcionalidade de
alterar status de um produto e seleciona o produto. O sistema altera
o status do produto no inventário.
Fluxo alternativo a) Esta função é executada automaticamente após "Adicionar
produtos na venda”, alterando o status do produto para “em
venda”;
b) Esta função é executada automaticamente após "Finalizar
Venda”, alterando o status do produto para “vendido”;
Fonte: Próprio autor
Tabela 16: Caso XV
Caso 14: Cancelar Venda
Elementos: Descrição:
Escopo Interface de Venda
Propósito Esse caso de uso permite ao autor cancelar uma venda
Ator Primário Supervisor
Pré-condições O funcionário deve possuir a permissão de supervisor para
conseguir cancelar uma venda.
Pós-condições Ao cancelar uma venda, o status de todos os produtos adicionados
são restaurados.
Fluxo normal O funcionário insere o seu login e depois a sua senha. O sistema
20
reconhece as credenciais e direciona o funcionário para a interface
das funcionalidades. O funcionário acessa a funcionalidade de
cancelar venda e seleciona a venda em andamento. O sistema
cancela a venda e restaura o status do produto.
Fluxo alternativo a) Esta função pode ser acessada em um terminal logado por
um atendente, mas abrirá uma nova aba de login para que o
supervisor insira suas credenciais.
Fonte: Próprio autor
Assim, com todos os casos de uso do ambiente “Vendas” definido, é possível
verificar o seguinte diagrama de casos de uso:
Figura 03: Diagrama de Casos de Uso - Vendas
Fonte: Próprio autor
7.0 REQUISITOS NÃO FUNCIONAIS (RNF)
Após a identificação dos requisitos funcionais através da modelagem de casos de
uso, da observação de regras de negócio e do detalhamento dos processos operacionais,
torna-se necessário determinar quais os Requisitos Não Funcionais (RNF) presentes no
sistema. Entretanto, deve-se debater sobre um requisito extremamente importante para
este projeto: acessibilidade.
O sistema voltado para gestão de estoque e vendas da GEEK LTDA deve ser
capaz de ser acessível para que eventuais portadores de deficiência consigam utilizá-lo.
21
Contudo, a doutrina clássica de Análise de Sistema ainda discute se a acessibilidade é
um requisito funcional ou não funcional. Nesta pesquisa, entende-se a acessibilidade
como um RNF, tendo em vista:
Requisitos não funcionais. São restrições aos serviços ou funções oferecidos pelo
sistema. Incluem restrições de timing, restrições no processo de desenvolvimento
e restrições impostas pelas normas. Ao contrário das características individuais ou
serviços do sistema, os requisitos não funcionais, muitas vezes, aplicam-se ao
sistema como um todo. (SOMMERVILLE, 2011, p. 73)
Assim, para além da acessibilidade, os RNF presentes neste projeto e suas
métricas de medição podem ser descritas, segundo Sommerville(2011), da seguinte
forma:
I. Usabilidade: deve ser medida através do tempo de treinamento padrão e o
número de frames de ajuda;
II. Confiabilidade e proteção: o sistema trata com diversos dados, tanto internos,
relacionados a produtos e registro de funcionário, como externos, a exemplo
dos dados cadastrais de clientes. Por isso, a confiabilidade e proteção devem
ser medidas em taxa de ocorrência de falhas, número de travas de segurança
e níveis de acesso, disponibilidade e tempo médio de falha;
III. Operacional: o sistema, apesar de armazenar grande quantidade de dados,
deve ser capaz de ser acessado nos desktops da organização sem muitos
problemas, sendo assim, é necessário uma compensação entre velocidade e
tamanho. Com este fim, as métricas utilizadas serão o tempo de resposta
usuário/evento, o número de chips de memória e o tamanho em Megabytes
do sistema.
6.0 DIAGRAMA DE CLASSES DE ANÁLISE
Para facilitar o entendimento e definir os requisitos sobre atributos e métodos de
cada classe que será criada neste projeto, desenvolveu-se um diagrama de análise de
classe que, também. identifica classes do tipo boundary, entity e control:
22
7.0 MODELO DE DADOS (MER).
Ainda visando o entendimento e a futura construção lógica do sistema, criou-se um
modelo conceitual de banco de dados baseado nas entidades e seus relacionamentos:
23
6.1 CONCLUSÃO
As principais etapas do Levantamento de Requisitos proposto na realização deste
trabalho foram concluídas. Muito embora, recomenda-se que, no futuro, desenvolva-se o
diagrama de atividades, para as atividades automatizadas, e o diagrama de sequência,
para ser suporte do diagrama de casos de uso. Além disso, sabe-se que é necessário a
implementação do modelo lógico no Banco de Dados apresentado. Portanto, esse projeto
encerra momentaneamente, mas com possibilidades de estudos futuros.
24
10.0 REFERÊNCIAS
SOMMERVILLE, Ian. Engenharia de Software; tradução Ivan Bosnic e Kalinka G de O.
Gonçalves ; revisão técnica Kechi Hirama. — 9. ed. — São Paulo : Pearson. Prentice Hall,
2011
PLAIS, Antonio. ArchiMate na Prática - Serviço de Negócio, Função de Negócio e
Processo de Negócio. CENTUS, 2016. Disponível em:
http://centus.com.br/comunidade/archimate-pratica-001#:~:text=Uma%20fun%C3%A7%C
3%A3o%20de%20neg%C3%B3cio%20agrupa,valor%20adicionado%20por%20uma%20o
rganiza%C3%A7%C3%A3o.. Acesso em 20 de abr. de 2023.