1

UNIVERSIDADE PAULISTA – UNIP Ead

Projeto Integrado Multidisciplinar

Curso Superior de Tecnologia em

Análise e Desenvolvimento de Sistemas

Gabriel de Sousa Santiago Gergye – 0616874

LEVANTAMENTO E ANÁLISE DE REQUISITOS

PARA SISTEMA DE VENDAS DE PRODUTOS GEEK

Mauá
2023
 2

Gabriel Sousa Santiago Gergye – 0616874

LEVANTAMENTO DE ANÁLISE DE REQUISITOS PARA SISTEMA DE VENDAS

DE PRODUTOS GEEK

Projeto Integrado Multidisciplinar em

Análise e Desenvolvimento de Projetos

Projeto Integrado Multidisciplinar para

obtenção do título de tecnólogo em Análise e
desenvolvimento de sistema, apresentado à
Universidade Paulista – UNIP Ead.

Orientador (a): Vanessa Santos Lessa

Mauá
2023
 3

RESUMO

O projeto teve como objetivo atender o que foi solicitado no projeto integrado
multidisciplinar, com o intuito de criar um sistema de gestão de uma loja de produtos
geek. Com objetivo de agilizar e controlar as vendas e recursos de apoio aos
superiores da loja. Matérias que servirão como base foram Banco de Dados, Analise
de sistema orientado a Objeto, Gestão Estratégica de RH com a integração dessas
matérias foi possível realizar o desenvolvimento das partes do projeto de forma
detalhada a interfaces do programa.

Palavras-Chave: Banco de Dados, Software, Análise de Requisitos.

 4

ABSTRACT

The project aimed to meet what was requested in the multidisciplinary integrated
project, with the aim of creating a management system for a geek product store. In
order to streamline and control sales and support resources for store superiors.
Materials that will serve as a basis were Database, Analysis of Object Oriented
System, Strategic HR Management with the integration of these materials it was
possible to carry out the development of the parts of the project in a detailed way to
program interfaces.

Keywords: Database, Software, Requirements Analysis.

 5

SUMÁRIO

1 Introdução ............................................................................................................... 9

2 O nosso Banco de dados ...................................................................................... 10

2.1 O que compõem esses modelos? .................................................................. 10

2.2 Entidades ........................................................................................................ 10

2.2.1 Tipos de Entidades ......................................................................................... 10

3 Caso de uso .......................................................................................................... 15

3.1 Requisitos ....................................................................................................... 15

3.1.1 Casos de uso .................................................................................................. 15

4 Elaboração das fases de teste .............................................................................. 17

4.1 Login ............................................................................................................... 17

4.2 Cadastro de Produtos ..................................................................................... 18

4.2.1 Requisitos Relacionados ................................................................................ 19

4.3 Tela Atendente ............................................................................................... 20

4.3.1 Requisitos Relacionados: ............................................................................... 22

4.4 Tela Venda ..................................................................................................... 23

5 Nosso Sistema ...................................................................................................... 24

5.1 Requisitos não funcionais ............................................................................... 24

5.1.1 Requisitos Funcionais ..................................................................................... 24

6 Qualidade .............................................................................................................. 26

6.1 Mps.br ............................................................................................................. 26

6.1.1 Nosso nível de maturidade ............................................................................. 27

7 Conclusão ............................................................................................................. 28

8 BIBLIOGRAFIA ..................................................................................................... 29
 6

ÍNDICE DE ILUSTRAÇÃO

Figura 1 : Modelo Conceitual..................................................................................... 12

Figura 2: Modelo Lógico ............................................................................................ 13
Figura 3: Modelo Lógico ............................................................................................ 13
Figura 4: Sistema de cadastro................................................................................... 16
Figura 5: Tela Login .................................................................................................. 17
Figura 6: Tela Cadastro ............................................................................................. 18
Figura 7: Funções que o estoquista .......................................................................... 19
Figura 8: Tela atendente ........................................................................................... 20
Figura 9: Confirmar Compra ...................................................................................... 21
Figura 10: Funções Atendente .................................................................................. 22
Figura 11: Tela venda ............................................................................................... 23
Figura 12: Níveis ....................................................................................................... 26
 7

DEDICATÓRIA

Dedicamos este trabalho a minha família em especial ao meus pais que sempre me
apoiaram em todas as escolhas de minha vida.
 8

AGRADECIMENTOS

Agradecemos em especial a instituição UNIP, ao desenvolvimento deste trabalho e

principalmente aos professores que nos orientaram da melhor forma possível para a
elaboração deste trabalho.
 9

1 Introdução

Em nosso cotidiano as soluções tecnológicas estão sendo procuradas para

automatização, produtividade, segurança e muito outros fatores trazendo muitas
melhorias para empresas, profissionais e pessoas que se beneficiam com essas
soluções.

Uma empresa do ramo de venda de jogos, acessórios e produtos geek vendo a

necessidade de obter um sistema que controle seu estoque e suas vendas nos
procurou para o desenvolvimento de um sistema com o objetivo de agilizar as vendas
e possuir um controle no estoque. Com isso, foi necessário um levantamento de
requisitos junto aos clientes, a identificação dos casos de uso onde temos como
principais casos de uso cadastro de clientes e cadastro de produtos, ambos têm
podem deletar, consultar e cadastrar.

Para efetuar a compra teremos os dados do cliente, que em confirmar compra a

gente pesquisa se já possui o cadastro dele no sistema, se não tiver apenas tem que
realizar o cadastro do mesmo. E por traz o sistema terá um banco de dados elaborado
e planejado para suprir todas permissões e necessidades do sistema, trazendo
segurança e informação de qualidade conforme os requisitos do cliente.
 10

2 O nosso Banco de dados

Para dar inicio ao Banco de Dados, partimos para o modelo conceitual o

famoso MER (Modelo Entidade Relacionamento), mas o que se trata esse modelo?

De acordo com Danielle Oliveira, o MER é utilizado para descrever os objetos

do mundo real através de entidades, com suas propriedades que são os atributos e
os seus relacionamentos, O DER (Diagrama Entidade-Relacionamento) é utilizado
para representar em forma gráfica o que foi descrito no MER (Modelo Entidade
Relacionamento).

2.1 O que compõem esses modelos?

2.2 Entidades

De acordo com Danielle Oliveira, as entidades representam um objeto do

mundo real e que possuem uma existência independente, como: pessoas, empresa,
carro, casa, entre outras coisas que podem ser representadas por uma entidade.
Podemos considerar que existem três tipos de entidades, as entidades fortes, que não
dependem de outras entidades para existirem.

2.2.1 Tipos de Entidades

De acordo com Carlos Alberto, existem as entidades:

• Uma entidade fraca (ou dependente): precisa de outra entidade para garantir
a sua existência. A entidade fraca depende de uma entidade tipo e esta relação
de dependencia é uma relação obrigatória. O identificador de uma entidade
fraca possui em sua composição o(s) atributo(s) identificador(es) da entidade
tipo à qual a entidade fraca está associada.
• As entidades associativas: são os resultados de relacionamentos m:m. Em
geral, as entidades associativas são encontradas entre entidades tipo. Muitas
das vezes, as entidades associativas têm nomes óbvios, pois ocorrem no
mundo real. Deve-se sempre procurar pelo nome adequado, pois esse irá
aumentar a clareza do modelo de dados.
• Entidade agregada: quando temos um conjunto de atributos que aparecem
em mais de uma entidade do modelo de dados. Ou seja, quando várias
entidades distintas têm atributos em comum. Nestes casos devemos criar uma
 11

entidade agregada contendo os atributos que se repetem em mais de uma

entidade.
• Entidade Subordinada: representa uma especialização de entidade no
modelo de dados onde uma entidade supertipo possui várias entidades
subordinada que são especializadas com atributos específicos. Devemos usar
entidades subordinadas toda vez que tivermos entidades que compartilham
conceitos semelhantes, mas que possuem características próprias.

2.2.1.1 Relacionamentos

As entidades podem se relacionar entre si, havendo assim uma associação, que
conhecemos como relacionamento, que normalmente são representados por verbos.
Como, por exemplo, “uma pessoa trabalha para uma empresa”.

• Relacionamento UM PARA UM (1:1): Onde uma entidade X se associa

unicamente a uma ocorrência da entidade Y.
• Relacionamento UM PARA MUITOS (1:N): Onde uma entidade X se
associa a várias ocorrências da entidade Y, porém, a entidade Y pode
apenas se associar a uma ocorrência da entidade X.
• Relacionamento MUITOS PARA MUITOS (N:N): Onde a entidade X o
pode se associar a várias ocorrências da entidade Y e a entidade
Y pode também se associar a várias ocorrências da entidade X.

2.2.1.1.1 Atributos e seus tipos:

De acordo com Danielle Oliveira Os atributos descrevem as propriedades das

entidades. Como as entidades, também existem alguns tipos de atributos, que são: os
atributos simples, atributos compostos, atributos multivalorados e atributos derivados

Atributos simples: são indivisíveis, ou seja, são atributos atômicos, um

exemplo seria o atributo CPF, ele não pode ser dividido em partes menores para
formar outros atributos, ele é indivisível.

Atributos Compostos: podem ser divididos em partes menores, que

representam outros atributos, como o atributo endereço, ele pode ser subdividido em
atributos menores, como, por exemplo, cidade, estado, rua, CEP.
 12

Atributo Multivalorado: pode ter um ou N (vários) valores associados a ele,

como, por exemplo, o atributo telefone de um cliente, ele pode ter um ou vários
telefones.

Atributos derivados: dependem de outro atributo ou até mesmo outra

entidade para existir, como, por exemplo, o atributo idade e o atributo data de
nascimento, para descobrimos a idade de uma pessoa precisamos da sua data de
nascimento, então, consideramos o atributo idade como derivado do atributo data de
nascimento.

Atributo chave: é utilizado para identificar de forma única uma entidade, ou

seja, os valores associados a esse atributo são distintos dentre o conjunto de
entidades. Como exemplo, podemos utilizar o CPF de uma pessoa, ele é único e pode
ser utilizado como atributo chave, já que cada pessoa recebe um número
de CPF distinto.

Figura 1 : Modelo Conceitual

Fonte: Autoria Própria

Esse é o modelo conceitual do projeto, com o levantamento de requisitos

consegui especificar atributos e relações que as entidades teriam. E para melhorar e
evitar erro, realizei a normalização de dados. Pois, sim o nível podia estar já
acoplado na entidade Funcionários, mas fica melhor eu não precisar colocar toda
vez escrito “Estoquista”, além de evitar erro de digitação, pois pode ocorre por causa
do usuário, fica bem mais fácil eu só puxar a chave estrangeira da tabela Nível.
Realizei o mesmo para forma de pagamento e categoria.
 13

Figura 2: Modelo Lógico

Fonte: Autoria Própria

Já no modelo lógico, só era preciso verificar se as chaves estrangeiras estavam

de maneira correta e fazendo ligação com as tabelas certas. E além disso verificar as
cardinalidades caso ocorresse algum tipo de erro.

Figura 3: Modelo Lógico

 14

Fonte: Autoria Própria

Por fim, no modelo lógico adicionei o incremento automático para o Id das

tabelas. Entretanto, acho melhor ter dois códigos para ser mais fácil a especificação
do item, e além disso coloquei “NOT NULL”, para os campos que precisam ser
preenchidos.
 15

3 Caso de uso

3.1 Requisitos

Em reunião com nosso cliente para a produção de um sistema para uma empresa
no ramo de vendas de jogas eletrônicos, acessórios e produtos geek, os sistemas em
um âmbito geral irá controlar o estoque dos produtos e as vendas.

O acesso ao sistema será através de login e senha com 3 níveis de acesso que
são Estoquista, Atendente e Supervisor. O estoquista terá acesso ao cadastro de
produtos será possível salvar, alterar, excluir e consultar os dados dos produtos que
terão as categorias de jogos, acessórios e produtos geek.

O atendente terá acesso ao cadastro do cliente, e o próprio terá a função de

cadastrar o cliente caso ele não tenha algum cadastro na loja, então podendo salvar,
alterar e excluir e por fim consultar os dados dos clientes. O atendente terá que realizar
as vendas da loja onde cada venda tem um código único, data, valores. Formas de
pagamento e status da compra e os dados do Cliente. O Supervisor terá acesso a
parte de venda, e quando necessário terá que realizar o cancelamento de vendas na
loja.

3.1.1 Casos de uso

• Cadastrar cliente
• Alterar cliente
• Excluir cliente
• Consultar cliente
• Cadastrar produto
• Alterar produto
• Excluir produto
• Efetuar venda
• Excluir produto da venda
• Cancelar venda
• Buscar cliente
• Consultar só por preço
• Efetuar login com nível de acesso
 16

Figura 4: Sistema de cadastro

 17

4 Elaboração das fases de teste

Para um software ser implementado de forma correta é necessário que este seja
testado para verificar seu funcionamento os testes são uma atividade incremental
realizadas em três fases: teste de unidade, teste de integração e teste de sistema.

Nos testes de unidade é realizada uma verificação minuciosa de cada pedaço

do software para verificar seu correto funcionamento, nos testes de integração não
mesclado alguns desses pedaços para verificar se então se comunicando de forma
correta e continuam realizando a função adequadamente.

4.1 Login

• Identificação: Realizar o Login.

• Escopo: Tela de login.
• Descrição do propósito: Esse caso de uso permite, ao usuário realizar o
login e para ocorrer corretamente dever ser informado o crachá, senha
e o nível correto para conseguir entrar no sistema.
• Ator primário: Usuário.
• Interessados: Usuário.

Figura 5: Tela Login

 18

4.2 Cadastro de Produtos

• Identificação: Cadastrar Produto.

• Escopo: Sistema de vendas e cadastro com controle de estoque.
• Descrição do propósito: Esse caso de uso permite ao estoquista realizar
o cadastro de produtos no sistema da loja
• Ator primário: Estoquista.
• Interessados: Loja e cliente.
• Pós-condição: Estoquista ou supervisor pegam os dados do produto e
salvam no sistema.

Figura 6: Tela Cadastro

O fluxo da tela é simples, o estoquista que será o único que possui acesso ao
sistema, após preencher os dados corretamente do produto e clicar o botão de
cadastrar irá realizar o cadastro do produto no sistema. Mas, caso ele esqueça
algum campo sem preencher irá aparecer uma tela informando que tem algum
campo vazio, e para cadastrar precisa preencher ele.
 19

E para editar ou deletar o produto precisa, clicar no código dele e selecionar o

botão editar ou deletar, ao clicar o deletar simplesmente irá aparecer que o produto
foi deletado com sucesso. Mas, se clicar em editar ele puxa as informações do
produto, para que assim possa altera algum campo do próprio, caso clique em outro
produto para editar também irá aparecer uma tela informando que tem que finalizar a
primeira operação para realizar outra.

Algumas prevenções que a tela tem, é que alguns campos como cpf e outro
só aceitam número, e para não ocorrer tantos erros coloquei em quantidade esse
item para não fugir tanto do proposito.

4.2.1 Requisitos Relacionados

• Alterar produtos
• Excluir produto
• Consultar produto
• Efetuar login com nível de acesso

Figura 7: Funções que o estoquista

 20

4.3 Tela Atendente

• Identificação: Efetuar venda.

• Escopo: Sistema de vendas e cadastro com controle de estoque.
• Descrição do propósito: Esse caso de uso permite ao atendente efetuar
a venda de produtos no sistema da loja.
• Ator primário: Atendente.
• Interessados: Loja e cliente.
• Pós-condição: Selecionar os produtos escolhidos e ir em finalizar
compra.

Figura 8: Tela atendente

 21

Figura 9: Confirmar Compra

Nesse fluxo, o atendente tem que necessariamente selecionar algum produto,

então deixei algumas possíveis quantidade que um cliente pode querer. Portanto, se
o atendente selecionar nada irá dar um erro informando que para finalizar a compra
precisa necessariamente algum produto.

E os produtos são adicionados, pressionando o código dele e a quantidade que

o cliente queira. Além disso a gente colocou uma barra de busca, que como foi
especificada só vai buscar pelo valor do produto.

E além disso, deixei duas etapas que pode haver o cancelamento da venda. A
primeira etapa é o cancelamento simples, onde o cliente não queira mais o produto o
atendente deve só clicar no código do produto e colocar em cancelar seleção, depois
vai aparecer que a ação foi realizada com sucesso. O outro cancelamento, é já na tela
confirmar compra onde para cancelar só o supervisor pode realizar esse
procedimento, depois que clicar em cancelar precisa da confirmação do supervisor de
plantão e depois ir em finalizar a compra novamente.

Em confirmar compra, é a parte onde o atende seleciona a forma de pagamento

informa ao cliente quanto que ficou. Caso o cliente de uma nota a mais vai ser
mostrado no troco quanto o atende deve dar de troco. E por fim, ao clicar em qualquer
produto já está realizando a baixa no sistema, ou seja, a quantidade do produto que
vai aparecer é a quantidade real que tem na loja.
 22

Figura 10: Funções Atendente

4.3.1 Requisitos Relacionados:

• Excluir produto
• Cancelar venda
• Buscar cliente
• Consulta preço
• Efetuar login com nível de acesso
 23

4.4 Tela Venda

• Identificação: Venda Realizada.

• Escopo: Sistema de vendas e cadastro com controle de estoque.
• Descrição do propósito: Esse caso de uso permite ao supervisor ter
acesso as vendas realizadas no dia.
• Ator primário: Supervisor.
• Interessados: Supervisor.
• Pós-condição: Selecionar vendas realizadas.

Figura 11: Tela venda

No fluxo da tela venda, é simples ocorre quando uma venda é realizada e se

foi cancelada o status irá mudar para “Cancelada”, mas se for sucesso irá aparecer
os dados do cliente que está sedo ligado por chave estrangeira pelo seu cpf, e além
disso vai aparecer os produtos adquiridos. Os produtos é apenas uma linha de com o
código do produto, nome e valor dele para que assim quando finalizar qualquer
compra seria necessário só imprimir essas informações e passar para o cliente.

A única pessoa que vai ter acesso para essa tela é o supervisor, pois ele que
é o responsável pelo monitoramento das vendas da loja. E depois, ele deve verificar
se tudo está correto como até o dinheiro que ficou no caixa.
 24

5 Nosso Sistema

5.1 Requisitos não funcionais

De acordo com Fernando Cunha, os requisitos funcionais são todos os problemas e

necessidades que devem ser atendidos e resolvidos pelo software por meio de
funções ou serviços. Alguns exemplos desse tipo de requisito:

• inserir dados em um formulário;

• buscar pratos específicos em um cardápio;
• consultar o status de um pedido;
• realizar compras;
• comunicar-se com um atendente;
• alterar informações de um registro;
• elaborar relatórios.

Tudo o que for relacionado a uma ação a ser feita é considerado uma função.
Também é importante lembrar que quanto menos ambíguos e mais objetivos forem
os requisitos funcionais, maior será a qualidade do software gerado.

5.1.1 Requisitos Funcionais

De acordo com Cairo Noleto, são aqueles que não interferem diretamente no
desenvolvimento do sistema propriamente dito, ou seja, não é um requisito que tem
regras de negócios e, portanto, é necessário para determinar o que será feito no
software. Em vez disso, os RNFs são requisitos que estabelecem como o sistema se
comportará em determinadas situações.

Em outras palavras, apesar de não interferirem em suas funcionalidades básicas, são

necessidades que podem impactar no objetivo final do software se não forem
contempladas em tempo de análise e desenvolvimento do projeto. Portanto, são
requisitos que se relacionam com a qualidade do software.
 25

5.1.1.1 Qual a estrutura de um Requisito Não Funcional?

Embora não exista uma estrutura obrigatória, algumas informações devem estar
presentes na definição de um requisito não funcional. A seguir, confira os principais
itens que devem ser discriminados no documento:

• identificador do requisito;
• nome ou descrição do requisito;
• categoria;
• data de criação;
• pessoa que criou o documento;
• data da última alteração;
• última pessoa que editou o documento;
• versão do documento;
• prioridade, que pode ser desejável, importante ou essencial;
• descrição detalhada.
 26

6 Qualidade

6.1 Mps.br

Ao iniciar a parte de programação é necessário definir os métodos de qualidade

os quais serão seguidos para evitar qualidade inaceitável e os prazos e orçamentos
não respeitados. Nesse caso nós iremos utilizar o modelo Mps.br para identificar a
maturidade da empresa, pois ele é mais barato e rápido de integrar em uma empresa.

De acordo com a Daiany Silva, o Mps.br ou Melhoria de Processos do Software

Brasileiro, é um modelo de qualidade de processo criado em 2003 pela Softex para
melhorar a capacidade de desenvolvimento de software nas empresas brasileiras.
Para a definição do MPS-BR levou em consideração normas e modelos
internacionalmente reconhecidos como CMMI (Capability Maturity Model Integration),
e nas normas ISO/IEC 12207 e ISO/IEC 15504 e na realidade do mercado brasileiro
de software.

Os níveis de maturidade no modelo MPS-BR estabelecem patamares de evolução

dos processos. O nível de maturidade em que se encontra uma organização permite
prever o seu desempenho futuro ao executar um ou mais processos. O modelo define
sete níveis de maturidade: A (Em Otimização), B (Gerenciado Quantitativamente), C
(Definido), D (Largamente Definido), E (Parcialmente Definido), F (Gerenciado) e G
(Parcialmente Gerenciado), sendo o nível G o primeiro a ser implementado e o nível
A o nível máximo que a empresa poderá atingir.

Figura 12: Níveis

 27

Apesar de ainda uma empresa pequena, nós temos objetivos bem visíveis e para
isso precisamos da colocação da qualidade em nossa forma de desenvolver os
sistemas, então iremos implementar desde o início esse método.

6.1.1 Nosso nível de maturidade

Nosso nível é o G (parcialmente gerenciado), para tal nível é necessário atingir

alguns atributos, assim como para que no futuro haja possiblidade de evolução.

De acordo com Mariano Montoni, ele é composto pelos seguintes processos:

Gerência de Projetos, Engenharia de Requisitos. Neste nível a implementação deve
atender a seguinte capacidade de processo: Capacidade do Processo Nível G
(CP G) – A execução do processo é gerenciada: Um processo de capacidade CP-G
deve produzir os resultados definidos, bem como a execução do processo deve ser
planejada e monitorada. Além disso, as pessoas devem estar preparadas para
executar suas responsabilidades no processo.

Como uma empresa ainda nova, nosso nível de maturidade ainda está se
desenvolvendo, entretanto, todas as empresas de software precisaram se adaptar aos
modelos de qualidade algum dia, assim sendo, começar essa adaptação desde o
início torna no futuro uma transição mais fácil até mesmo para um modelo
internacional de qualidade visto que atualmente o modelo Mps.br ser um modelo muito
eficiente abre muitas portas para o governo brasileiro, porém ela é só vista no território
brasileiro.

Sendo assim como nosso objetivo é um crescimento calmo e com decisões bem
pensadas, se torna a melhor escolha, além do fato de nossa empresa pelo menos de
momento não ter a intenção de sair do território nacional e sim de no futuro
desenvolver sistemas para o governo de nosso país, o qual já solicita que a empresas
que trabalhem para ele tenham o selo de qualidade Mps.br.
 28

7 Conclusão

O projeto teve como objetivo o desenvolvimento de um sistema para uma loja

que realiza vendas de produtos geek, que teve como propósito agilizar e controlar o
estoque da loja e supervisionar ela. A bases desse projeto são as disciplinas de
Analise e gestão de RH, Programação orientada a objetos, Banco de dados e Análise
Orientada a Objeto. Seu objetivo era poder realizar cadastro de novos usuários e
clientes, salvando seus dados em um banco de dados relacional, para recuperação
posterior.

Serviu como exercício da teoria estudada nas matérias citadas anteriormente,

demonstrou de maneira pratica como sugiram os problemas durante a programação
e suas respectivas soluções no decorrer do projeto.

A metodologia adotada foi a de pesquisa bibliografia fundamentada nos

principais autores disponíveis sobre o tema em questão, para melhor embasamento
teórico das práticas adotadas.

Para definir a estrutura do banco de dados foi utilizado o modelo entidade

relacional (Mer), e Diagrama Entidade Relacional (Der), também foi apresentado o
diagrama de classes de análise, com este diagrama podemos modelar de forma mais
precisa o software do cliente e os dados a serem armazenados.

Conforme detalhado nesse trabalho o projeto em questão foi realizado e

concluído, assim concluindo seu objetivo de detalhar de maneira técnica e visual como
o programa em questão iniciou seu planejamento e como sua interface foram
desenvolvidas, sendo assim a parte documental desse documento, que era parte
fundamental desse trabalho.
 29

8 BIBLIOGRAFIA

Alura , Danielle Oliveira. Banco de dados. https://www.alura.com.br/artigos/mer-e-

der-funcoes,

Daiany Silva. Qualidade. https://blogdaqualidade.com.br/o-que-e-o-mps-br/.

Mestresdaweb, Fernando Cunha. Requisitos funcionais.

https://www.mestresdaweb.com.br/tecnologias/requisitos-funcionais-e-nao-
funcionais-o-que-sao

Blog.betrybe, Cairo Noleto. Requisitos não funcionais. https://blog.betrybe.com/tecn

ologia/requisitos-nao-funcionais/

Promovesolucoes, Mariano Montoni. Nosso Nivel de qualidade.

https://promovesoluc oes.com/quais-sao-os-niveis-de-maturidade-do-mps-br/

Cadcobol, Carlos Alberto, Tipos de Entidades.

https://www.cadcobol.com.br/db2_novo_tipos_entidade.htm