PIM VI Loja Geek

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 
 
 
PAULO ROBERTO BORGES JUNIOR – RA 2200042 
 
 
 
LEVANTAMENTO E ANÁLISE DE REQUISITOS DE UM SISTEMA DE 
CONTROLE DE VENDAS DE UMA LOJA DE JOGOS, ACESSÓRIOS E 
PRODUTOS GEEK. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
LAPA 
2023 
 
 
2 
 
 
 
 
 
PAULO ROBERTO BORGES JUNIOR – RA 2200042 
 
 
LEVANTAMENTO E ANÁLISE DE REQUISITOS DE UM SISTEMA DE CONTROLE 
DE VENDAS DE UMA LOJA DE JOGOS, ACESSÓRIOS E PRODUTOS GEEK. 
 
 
 
Projeto Integrado Multidisciplinar para obtenção do título de tecnólogo em 
Análise e Desenvolvimento de Sistemas 
Orientador (a): VANESSA SANTOS LESSA 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
LAPA 
2023 
 
3 
 
 
 
 
 
RESUMO 
 
 
Esse projeto tem o principal objetivo de desenvolver o levantamento e análise 
de Requisitos de um sistema de controle de vendas de uma loja de jogos, acessórios 
e Produtos Geek, devido à baixa eficácia na forma em realizar as pequenas tarefas 
Gerenciadas para controlar as vendas. Devido a essa baixa do controle de vendas 
atualmente sendo gerenciado em uma Planilha eletrônica Excel, surgiu a necessidade 
de melhoria desenvolvendo um novo sistema desktop robusto, compacto e eficaz, que 
tenha módulos de acessibilidade para que, os eventuais usuários portadores de 
deficiência consigam utilizá-lo sem problemas no Gerenciamento do controle de 
vendas. Para o desenvolvimento do projeto serão utilizadas e embasadas as 
disciplinas vigentes do Bimestre, Banco de Dados, Análise de Sistemas Orientada a 
Objetos e gestão Estratégica de RH. 
 
 
 
 
 
Palavras-chave: Engenharia de Software. Orientação a Objetos. Banco de Dados. 
Gestão de Recursos Humanos. 
 
 
 
 
 
 
 
 
 
4 
 
 
ABSTRACT 
 
 
This project has the main objective of developing the survey and analysis of 
Requirements of a sales control system for a game store, accessories and Geek 
products, due to the low effectiveness in the way of performing small tasks Managed 
to control sales. Due to this drop in sales control currently being managed in a Excel 
spreadsheet, the need for improvement arose by developing a new robust, compact 
and effective desktop system, which has accessibility modules so that Any users with 
disabilities can use it without problems in the Sales Control Management. For the 
development of the project, the current disciplines of the Bimester, Database, Object 
Oriented Systems Analysis and management HR Strategy. 
 
 
 
 
 
Keywords: Software Engineering, Object orientation, Database, Human resource 
Management. 
 
5 
 
 
Sumário 
1 INTRODUÇÃO ......................................................................................................... 6 
2 DESCRIÇÃO DO SISTEMA ATUAL ........................................................................ 6 
2.1 Problemas Existentes ............................................................................................ 6 
2.2 Desejos do Cliente ................................................................................................ 7 
3 SOLUÇÕES DE SISTEMAS DISPONÍVEIS NO MERCADO ................................... 7 
4 TIME DE DESENVOLVIMENTO .............................................................................. 7 
5 LEVANTAMENTO DE REQUISITOS E METODOLOGIA ........................................ 8 
5.1 Requisitos .............................................................................................................. 8 
5.1.1 Funcionais .......................................................................................................... 9 
5.1.2 Não Funcionais ................................................................................................ 11 
5.2 Regra de Negócio ............................................................................................... 12 
5.3 casos de uso ....................................................................................................... 13 
5.3.1 Definição dos Atores ........................................................................................ 14 
5.4 diagramas de classes .......................................................................................... 15 
5.4.1 Descrição das Classes ..................................................................................... 16 
6 MODELO ENTIDADE RELACIONAMENTO .......................................................... 16 
7 CONCLUSÃO ......................................................................................................... 18 
REFERENCIAS ......................................................................................................... 19 
 
 
 
 
 
 
 
 
 
6 
 
1 INTRODUÇÃO 
 
O projeto trata-se do levantamento e análise de requisitos de um sistema 
Computacional a ser desenvolvido para substituir o atual "sistema" de uma loja de 
Produtos geeks, juntamente com a solução e funcionalidade trazer uma solução 
tecnológica que facilite a usabilidade e traga desempenho e agilidade para a loja. No 
projeto será apresentado, conceitos e metodologia da engenharia de software que irá 
apresentar os princípios para uma bom levantamento e análise de Requisitos. Além 
dos conceitos da área de Recursos Humanos, para contextualizar o processo de 
seleção de um time de desenvolvimento para concepção do projeto e conceito do 
banco de dados para definição de um modelo de entidade relacional que irá 
representar o comportamento dos dados no SGBD. 
 
2 DESCRIÇÃO DO SISTEMA ATUAL 
 
 O cliente contratante para o desenvolvimento do projeto, tem um método de 
trabalho onde a eficiência não está sendo atingida. O sistema atual de controle de 
vendas trata-se por meio da planilha eletrônica Excel, onde o funcionário preenche a 
planilha e faz a atualização 
 
2.1 Problemas Existentes 
 
Tendo conhecimento do sistema atual de trabalho da empresa para o 
gerenciamento de vendas, são feitos a partir de planilhas no Excel. Dessa forma a 
empresa não transmite eficácia e nem segurança aos dados, que por compor muitas 
planilhas e dados, acarreta na demora da inserção e extração de dados, por exemplo. 
Outro problema é que não existe um controle de acesso ao “sistema”, qualquer 
usuário com a senha pode acessar módulos que eram para ser restritos. Como por 
exemplo, o módulo de cancelamento de uma venda que deve ser realizado por um 
supervisor e não pelo atendente, o máximo de “segurança” que pode ser atribuída 
com o 'gerenciamento” atual de acesso é definir que o usuário possa ler, más não 
modificar o conteúdo, sendo essa podendo ser burlada. 
 
7 
 
2.2 Desejos do Cliente 
 
A partir dos problemas expostos, faz se necessárias mudanças nos sistemas 
atuais utilizados. A implantação de um sistema automatizado onde o seu acesso será 
restrito a diferentes funções tem como objetivo principal agilizar todo o processo de 
gerenciamento e integralidade de dados. 
 
3 SOLUÇÕES DE SISTEMAS DISPONÍVEIS NO MERCADO 
 
Existem diversas opções de sistemas de gerenciamento disponíveis no 
mercado. Em uma rápida pesquisa na Web com o termo “sistema de gerenciamento 
de vendas” diversos resultados aparecem na pesquisa. Na maioria das opções são 
sistemas já prontos que a empresa adquiri por meio de uma licença. 
Como cenário para efeito de pesquisa, para esse projeto foi realizado 
pesquisas em um dos sites mais famosos e visitados na web, o Mercado Livre. Ao 
pesquisar pelo termo “sistema de gerenciamento” a plataforma retorna como resultado 
para venda diversos sistemas já prontos para usar com assinatura vitalícia O que 
chama atenção é que nas descrições do anunciante, o sistema vem com quase/ou 
nenhuma modificação caso o cliente deseje. O fator citado é um dos mais prejudiciais 
ao cliente, já que não se tem a seguridadede adquirir um sistema com suporte e, 
atualizações, além do comprador não poder exigir nenhum requisito adicional no 
sistema. 
Com um sistema criado do zero, o cliente faz jus a um sistema que irá ter todos 
os atributos de sucesso citados no fator prejudicial. Em um sistema com a criação do 
zero, o cliente pode definir todos os requisitos e regras ao decorrer do 
desenvolvimento, além de poder contar com um time de suporte ao sistema e ser dono 
do próprio sistema, não necessitando de renovação de assinaturas ou correr o risco 
de ficar sem o sistema, caso algum dia o fabricante do sistema deixe de operar o 
sistema. 
 
4 TIME DE DESENVOLVIMENTO 
O custo de produção do sistema solicitado é de 30.000 mensais, com o prazo 
de entrega para 3 meses. Atualmente a fábrica de software SoftLab (fábrica fictícia, 
que irá produzir o sistema) está com todas as equipes elencadas a projetos em 
8 
 
andamento. Nesse contexto a SoftLab precisa contratar um novo time de 
desenvolvedores para a fabricação do sistema. O líder técnico responsável pelo 
projeto solicitou a equipe de Recursos Humanos, identificar possíveis profissionais 
para montar um novo time de desenvolvimento. 
Os profissionais responsáveis para identificar o novo time de desenvolvimento, 
são os recrutadores técnicos. Os recrutadores técnicos devem identificar os seguintes 
profissionais: 1 Scrum Master, 4 programadores (1 júnior, 1 pleno e 2 sêniores), 2 
analistas de qualidade e 1 coordenador de projetos. 
O papel do tech recruiter é selecionar os perfis aderentes a vagas e fazer a 
primeira entrevista de seleção para passar para área técnica responsável, já que estes 
profissionais têm skills voltadas especialmente para capturar pessoas da área de TI. 
Os candidatos aprovados em todos os processos são encaminhados para área 
admissional dos Recursos Humanos. 
 
5 LEVANTAMENTO DE REQUISITOS E METODOLOGIA 
 
 O desenvolvimento desse sistema. é apoiado na metodologia de 
desenvolvimento ágil Scrum. Esse modelo de desenvolvimento é incremental 
interativo, onde o desenvolvimento é composto por miniprojetos que são 
desenvolvidos ao longo do ciclo que duram em torno de 1 a 4 semanas. 
O ágil é um dos modelos mais utilizado no mundo, já que que sua interação é 
continua entre desenvolvedores e clientes, a fim de entregar um produto de qualidade 
no final do projeto, já que o produto passa por constante feedbacks ao decorrer do 
ciclo de desenvolvimento 
 
5.1 Requisitos 
 
Os requisitos são as descrições das características e funcionalidades que 
devem ser realizadas por um sistema. Nesse contexto engloba as necessidades de 
um usuário, exigências do negócio, desejos da empresa, entre diversas outros fatores 
que englobam os requisitos que deve ser materializado em um sistema. 
No contexto de requisitos duas grandes categorias se destacam, que são os 
funcionais e os não funcionais. Os requisitos funcionais descrevem e expressam o 
9 
 
comportamento do sistema, ou seja, são os requisitos funcionais que especificam 
ações que o sistema deve executar. 
Os requisitos não funcionais especificam as ações como o todo do sistema que 
define como o sistema fará as ações. Os requisitos não funcionais têm como requisitos 
o desempenho, atributos de qualidade, usabilidade, entre diversos outros requisitos 
de grande importância no desenvolvimento de um sistema, que define a seleção na 
escolha de alternativas de projeto, estilo arquitetural e forma de implementação. 
 
 5.1.1 Funcionais 
 
 Abaixo, seguem descritos os requisitos funcionais do sistema, descritos por módulo, 
ordem, identificação, classificação, ator e objetivo. 
. Acesso 
. Identificação: Efetuar Logui; 
. Classificação: Importante; 
. Ator: Funcionário; 
. Objetivo: Esse quesito especifica um caso de uso em que o usuário só tem acesso 
permitido ao sistema por meio de um Loguin, informando usuário e senha. 
 
. Cliente 
 
. RF002 
. Identificação: Cadastro de Clientes; 
. Classificação: Essencial; 
. Ator: Cliente; 
. Objetivo: Esse requisito especifica o caso de uso em que os clientes devem ser 
cadastrados com as seguintes informações pessoais: RG, CPF, nome, data de 
nascimento, data de cadastro, endereço, telefone, e-mail e um código de identificação 
(código a ser gerado pelo sistema automaticamente). 
 
. Estoque 
 
. RF003 
. Identificação: Cadastro de Produtos; 
10 
 
. Classificação: Essencial; 
. Ator: Funcionário; 
. Objetivo: Esse reqiosito especifica o caso de uso em que os produstos a serem 
vendidos devem ser cadastrados no sistema, os quais deverão ser divididos por 
categorias: Jogos, acessórios geeks. 
. RF004 
. Identificação: Descrição de Produtos; 
. Classificação: Essencial; 
. Ator: Funcionário; 
. Objetivo: Esse requisito especifica o caso de uso em que todos os produtos 
cadastrados no sistema devem possuir as seguintes informações de identificação; 
Código de barras, nome do produto, categoria, fabricante, quantidade e valor do 
produto. Para os jogos e os acessórios, devem ser informados em qual plataforma 
serão utilizados e qual o prazo de garantia que o Produto possui. 
Todas essas informações serão utilizadas para gerenciamento no estoque e 
apresentação na nota fiscal do consumidor. 
 
. Venda 
 
. RF005 
. Identificação: Processo de venda; 
. Classificação: Essencial; 
. Ator: Funcionário; 
. Objetivo: Esse requisito especifica o caso de uso em que a venda devera possuir os 
dados do cliente e todos os produtos adquiridos. Para a venda, tambem deverá ser 
gerado um código único de venda, com a data da venda, o valor da venda, opções 
para agendamento, status de pagamento e status de venda. 
 
. RF006 
. Identificação: Exclusão de produtos; 
. Classificação: Essencial; 
. Ator: Funcionário; 
. Objetivo: Esse requisito especifica o caso de uso em que o atendente poderá excluir 
produtos da venda caso o cliente não queira mais adquiri-los. Logo, apenas o 
11 
 
supervisor da loja poderá permitir a função de exclusão do produto da venda, devendo 
informar um usuário e senha validos. 
 
. RF007 
. Identificação: Cancelamento de Venda; 
. Classificação: Essencial; 
. Ator: Funcionário; 
. Objetivo; esse requisito especifica o caso de uso em que o atendente poderá 
cancelar uma venda caso o cliente não queira prosseguir. Logo apenas o supervisor 
da loja poderá permitir a função de exclusão do produto da venda, devendo informar 
um usuário e senha validos, no momento do cancelamento o código do cancelamento 
da venda deverá ser enviado ao usuário do sistema financeiro. 
 
. RF008 
. Identificação: Consulta de Preços; 
. Classificação: Essencial; 
. Ator: Funcionário; 
. Objetivo; esse requisito especifica o caso de uso em que o atendente poderá 
consultar os preços dos produtos. 
 
 5.1.2 Não Funcionais 
 
 Abaixo, seguem descritos os requisitos não funcionais do sistema, descritos Por 
módulo, ordem, identificação, classificação e objetivo. 
 
 
. Desempenho 
. RNF001 
. Identificação: Requisitos de configuração; 
. Classificação: Importante; 
. Objetivo; esse requisito especifica os requisitos mínimos de configuração que um 
computador deve ter para rodar o sistema. 
. Requisitos de configuração do sistema computacional. 
12 
 
. 10 GB de espaço no disco rígido. 2 GM de memória ram . Processador Dual Core 
2.8 GHZ. Sistema operacional Windows 7/Linux 15.10. Usabilidade. 
 
RNF002 
 . Identificação: Interface do usuário; 
. Classificação: Essencial; 
. Objetivo; esse requisito especifica o requisito de usabilidade apoiado nos princípios 
da interface do usuário, onde é explicito que um sistema deve fornecer um sistema 
amigável. E por necessidade do cliente. O sistema deve atender módulos de 
acessibilidade para que eventuais usuários portadores de deficiência consigam utilizá-
lo. 
 
. Confiabilidade 
. RNF003 
. Identificação:Rotina de Backups; 
. Classificação: Importante; 
. Objetivo; Esse requisito especifica a necessidade do sistema quanto a confiabilidade 
dos dados, sendo necessário a realização do backup diariamente do sistema. 
 
. Segurança 
. RNF004 
. Identificação: Autenticação de Acessos; 
. Classificação: Importante; 
. Objetivo; esse requisito especifica a necessidade do controle de acessos ao sistema 
e ao banco de dados. Para o acesso a esses sistemas é necessário o uso de Login 
contendo usuário e senha com níveis de privilégio. 
 
5.2 Regra de Negócio 
 
A regra de negócio é um conceito associado ao domínio de aplicação tratado 
no desenvolvimento de software. A regra de negócio pode ser independente do mundo 
computacional. As regras de negócio a seguir são baseadas nos requisitos funcionais 
levantados anteriormente. 
 
13 
 
. Compatibilidade. 
. RNF005 
. Identificação: Compatibilidade em sistemas Operacionais; 
. Classificação: Essencial; 
. Objetivo: Esse requisito especifica a necessidade do sistema ser compatível com 
diferentes sistemas computacionais presentes na empresa, que são eles, Windows e 
Linux. 
 
. Interoperabilidade. 
. RNF006 
. Identificação: Integração com API de emissão de notas fiscais; 
. Classificação: Importante; 
. Objetivo: Esse requisito especifica a necessidade do sistema se comunicar com a 
API do órgão competente do estado onde o sistema esta alocado, para a emissão de 
notas fiscais. . Nome: Forma de Pagamento; 
. Descrição: Deve ser oferecidas diversas formas de pagamento. 
 
. RN01 
. Nome: Baixa de cancelamento de venda; 
. Descrição: Após cancelamento de uma venda a informação deve ser enviada para o 
modulo financeiro. 
 
. RN02 
. Nome: Consulta de preço; 
. Descrição: Consulta de preço de um produto no sistema para agilizar a informação 
caso o cliente necessite saber preço de um produto. 
 
. RN03. Nome: Exclusão de produtos; . Descrição: Exclusão de um produto no 
processo de venda. 
 
 5.3 casos de uso 
 
 O caso de uso tem como objetivo a descrição de como será o uso de uma 
funcionalidade de um sistema. Na Linguagem de modelagem unificada (UML), o 
14 
 
diagrama de caso de uso resume os detalhes dos usuários do seu sistema (também 
conhecidos como atores) e as interações deles com o sistema. É importante notar que 
não descreve como o software deverá ser construído, mas sim como ele deverá se 
comportar quando estiver pronto. Um software frequentemente é um produto 
complexo, e sua descrição envolve a identificação e documentação de vários casos 
de uso, cada um deles descrevendo uma "fatia" do que o software ou uma de suas 
partes deverá oferecer. 
 
5.3.1 Definição dos Atores 
 
Os atores de um caso de uso são pessoas ou sistema que interagem 
diretamente com o sistema um ator pode invocar vários casos de uso e um caso de 
uso pode ser invocado por vários atores De acordo com Furlan (1998, p.175), “o ator 
comunica-se com o sistema a través do envio e recebimento de mensagens, sendo 
que um caso de uso é sempre iniciado a partir do momento que um ator envia sua 
mensagem (estímulo) ”. 
 A figura 1 representa os atores que irão participar dos cenários, baseados a 
partir das regras de negócio. O ator funcionário responsável pelas rotinas de processo 
de venda, exclusão, cadastro etc. Nota: Foi adotado o conceito de herança do ator 
funcionário sendo elencados 3 filhos: Atendente, supervisor e Estoquista. O ator 
cliente sendo o afetado direto pelas ações do ator funcionário. 
O ator Sistema Financeiro responsável pela rotina de processamento de venda 
e cancelamento. 
 
 
 
 
15 
 
5.4 diagramas de classes 
 
O diagrama de classes está entre os mais utilizados e mais úteis de diagramas 
UML. O digrama modela a estrutura de um sistema ou produto de software, suas 
classes, seus atributos, operações e relações entre objetos. 
O diagrama de classes é poderosa ferramenta para a documentação de um 
sistema ou produto de software, sendo uma das técnicas mais utilizadas no 
desenvolvimento orientado a objetos. 
Na figura 2 é apresentado o diagrama de classes, contendo relação entre 
classes. Nesse diagrama UML é tratado o termo tem um (representado pelo número 
1) e o termo tem vários (representado pelo símbolo *) para a relação entre classes. 
 
 
 
Figura 3 — Diagrama de Classes 
16 
 
 
 
5.4.1 Descrição das Classes 
 
. Cliente: Essa classe define os atributos e métodos necessários para “manipular” o 
cliente no sistema. Essa classe tem relação com a classe endereço, que recebe os 
atributos e métodos para manipular um endereço ao cliente. 
. Endereço: Essa classe define os atributos e métodos para “manipular” o processo 
de venda no sistema. 
. Venda: Essa classe define os atributos e métodos para “manipular” o processo de 
venda no sistema. Essa classe tem relação com a classe produto, que recebe os 
atributos e métodos para manipular o produto no processo de venda, que tambem tem 
relação com a classe, Forma de pagamento que recebe atributos e métodos para 
manipular a forma de pagamento no processo de venda. 
. Produto: Essa classe define os atributos e métodos para manipular o produto no 
sistema. Essa classe essa classe tem relação com a classe categoria, que define os 
atributos e métodos para definir uma categoria ao produto. 
. Categoria: Essa classe define os atributos e métodos para definir uma categoria ao 
produto. 
. Estoque: Essa classe define os atributos e métodos para manipular um produto no 
estoque. Essa classe tem relação com a classe produto. 
. Financeiro: Essa classe define os atributos e métodos para manipular as vendas no 
modulo financeiro. Essa classe tem relação com a classe venda. 
. Funcionário: Essa classe define os atributos e métodos para manipular o acesso de 
funcionários nas funcionalidades do sistema. 
. Atendente: Estoquista, Supervisor, essas classes filhas herdam da classe pai 
Funcionário. 
 
 
 
6 MODELO ENTIDADE RELACIONAMENTO 
Nesse projeto, o Banco de Dados utilizado foi o MySQL relacional em sua 
versão 8.0.25.0. O MySql é um dos SBDA mais utilizados no mundo, devido a sua 
17 
 
facilidade e desempenho, por esse motivo foi adotado nesse projeto. Abaixo, na figura 
3 é representado o modelo de entidade relacionamento do banco de dados. 
 
 
Figura 4 — MER 
 
 
 
 
 
 
 
 
 
 
 
 
 
18 
 
7 CONCLUSÃO 
Diante da contextualização do caso proposto, foi realizado o levantamento e 
análise de requisitos de um novo sistema tecnológico que substitui o atual "sistema" 
de controle de vendas feito no Excel, utilizado tecnologias e metodologias para 
confecção do projeto. 
Com o apoio dos conceitos das disciplinas cursadas no atual bimestre, foi 
confeccionado a análise e levantamento de requisitos de um novo sistema funcional 
para loja de produtos geeks. 
Utilizando os conceitos da disciplina Análise Orientada a Objetos, foi possível 
definir os requisitos, regras de negócio e caso de uso para o sistema. 
Com a disciplina Gestão de RH foi possível contextualizar a equipe de RH 
responsável por procurar novos desenvolvedores para o cenário proposto. 
A disciplina de Banco de Dados, foi utilizada para definir o modelo de entidade 
de relacionamento do sistema. 
Ao final foi possível a criação de um projeto viável e funcional, obedecendo as 
metodologias e análises para o desenvolvimento do mesmo. 
 
19 
 
REFERENCIAS 
 
CAVALCANTI, ANDERSON. Modelo de Casos de Uso e Diagrama de Casos de Uso. 
DEPARTAMENTO DE ENGENHARIA DE COMPUTAÇÃO E AUTOMAÇÃO. 
Disponível em: https://www.dca.ufrn.br/~anderson/FTP/dca0120/P2_Aula3.pdf. 
Acesso em: 04 mai. 2023. 
PEREIRA, ROBERTO. Casos de Uso. LInterHAD. Disponível em: 
https://interhad.nied.unicamp.br/courses/roberto-pereira/ci163-projeto-de-software-
ufpr-1/agenda/cap02-1-mar2013.pdf . Acesso em: 04 mai. 2023. 
VENTURA, Plínio. O que é Requisito Funcional.Disponível em: 
https://www.ateomomento.com.br/o-que-e-requisito-funcional/ . Acesso em: 18 mai. 
2023 . VENTURA, Plínio. O que é um Requisito Não-Funcional. Disponível em: 
https://www.ateomomento.com.br/o-que-e-um-requisito-nao-funcional/. Acesso em: 
19 mai. 2023 . 
VIANA, Davi. Partindo dos processos de negócio e chegando aos requisitos de 
sistemas. dheka. Disponível em: https://www.dheka.com.br/processos-de-negocio-e-
requisitos-de-sistemas/ . Acesso em: 19 mai. 2023. 
https://www.dca.ufrn.br/~anderson/FTP/dca0120/P2_Aula3.pdf
https://interhad.nied.unicamp.br/courses/roberto-pereira/ci163-projeto-de-software-ufpr-1/agenda/cap02-1-mar2013.pdf
https://interhad.nied.unicamp.br/courses/roberto-pereira/ci163-projeto-de-software-ufpr-1/agenda/cap02-1-mar2013.pdf
https://www.ateomomento.com.br/o-que-e-requisito-funcional/
https://www.ateomomento.com.br/o-que-e-um-requisito-nao-funcional/
https://www.dheka.com.br/processos-de-negocio-e-requisitos-de-sistemas/
https://www.dheka.com.br/processos-de-negocio-e-requisitos-de-sistemas/
	1 INTRODUÇÃO
	2 DESCRIÇÃO DO SISTEMA ATUAL
	2.1 Problemas Existentes
	2.2 Desejos do Cliente
	3 SOLUÇÕES DE SISTEMAS DISPONÍVEIS NO MERCADO
	4 TIME DE DESENVOLVIMENTO
	5 LEVANTAMENTO DE REQUISITOS E METODOLOGIA
	5.1 Requisitos
	5.1.1 Funcionais
	5.1.2 Não Funcionais
	5.2 Regra de Negócio
	5.3 casos de uso
	5.3.1 Definição dos Atores
	5.4 diagramas de classes
	5.4.1 Descrição das Classes
	6 MODELO ENTIDADE RELACIONAMENTO
	7 CONCLUSÃO
	REFERENCIAS