PIM VI - Levantamento e Análise de Requisitos para Sistema de Venda de Jogos e produtos geek

Prévia do material em texto

UNIP EaD 
Projeto Integrado Multidisciplinar 
Curso Superior de Tecnologia 
 
 
 
 
 
 
 
 
 
 
 
 
LEVANTAMENTO E ANÁLISE DE REQUISITOS DE UM SISTEMA PARA VENDA 
DE JOGOS ELETRÔNICOS, ACESSÓRIOS E PRODUTOS GEEK 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Pólo XXXXXXXX 
2020 
 
 
UNIP EaD 
Projeto Integrado Multidisciplinar 
Curso Superior de Tecnologia 
 
 
 
 
 
 
 
 
 
 
 
 
LEVANTAMENTO E ANÁLISE DE REQUISITOS DE UM SISTEMA PARA VENDA 
DE JOGOS ELETRÔNICOS, ACESSÓRIOS E PRODUTOS GEEK 
 
 
 
 
 
Aluno: XXXXX XXXXX XXXXX XXXXX 
RA: XXXXXXX 
Curso: Análise e Desenvolvimento de Sistemas 
Semestre: X 
 
 
 
 
 
 
Pólo XXXXXXXX 
2020 
 
 
RESUMO 
 
Este trabalho consiste na elaboração de um levantamento e análise de requisitos de 
um sistema para empresa destinada à venda de jogos eletrônicos, acessórios e 
produtos geek. A elaboração será baseada conforme os conhecimentos adquiridos 
nas disciplinas: Análise de Sistemas Orientada a Objetos; Banco de Dados; Gestão 
Estratégica de Recursos Humanos. Com o avanço da tecnologia, atualmente, as 
pequenas tarefas gerenciadas para controle de vendas são manipuladas pelas 
planilhas do Excel. Pensando em uma melhoria no atendimento ao cliente, a empresa 
fechou um contrato para o desenvolvimento de um software de controle e 
gerenciamento de vendas, solicitando o levantamento e a análise de requisitos do 
sistema, para que seja organizada nos cadastros, alterações, consultas e exclusões, 
o sistema será utilizado por atendentes, estoquistas e o supervisor da loja. 
 
Palavras chaves: Venda de jogos. Controle de vendas. Controle de estoque. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
ABSTRACT 
 
This work consists in the elaboration of a survey and analysis of requirements of a 
system for a company destined to the sale of electronic games, accessories and geek 
products. The elaboration will be based on the knowledge acquired in the disciplines: 
Object Oriented Systems Analysis; Database; Strategic Human Resource 
Management. With the advancement of technology, currently, small tasks managed to 
control sales are handled by Excel spreadsheets. Thinking of an improvement in 
customer service, the company closed a contract for the development of software for 
sales control and management, requesting the survey and analysis of system 
requirements, so that it is organized in the registrations, changes, consultations and 
exclusions , the system will be used by attendants, stockists and the store supervisor. 
 
Keywords: Sale of games. Sales control. Inventory control. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
SUMÁRIO 
 
 
INTRODUÇÃO ............................................................................................................ 6 
1. O LEVANTAMENTO E A ANÁLISE DE REQUISITOS DE UM SISTEMA .............. 6 
2. REQUISITOS DO SOFTWARE ............................................................................... 7 
2.1 REQUISITOS FUNCIONAIS .............................................................................. 7 
2.2 REQUISITOS NÃO FUNCIONAIS ..................................................................... 8 
2.3 REQUISITOS E REGRAS DE NEGÓCIO .......................................................... 8 
3. METODOLOGIA DE QUALIDADE .......................................................................... 9 
4. OBJETOS .............................................................................................................. 11 
5. CLASSES .............................................................................................................. 11 
6. HERANÇA ............................................................................................................. 12 
7. POLIMORFISMO................................................................................................... 13 
8. ENCAPSULAMENTO ............................................................................................ 14 
9. ELEMENTOS TÉCNICOS DO SISTEMA .............................................................. 14 
9.1 DIAGRAMA DE CLASSES............................................................................... 14 
9.2 DIAGRAMA DE OBJETOS .............................................................................. 15 
10. TELA DE CADASTRO ......................................................................................... 16 
CONCLUSÃO ............................................................................................................ 20 
REFERÊNCIAS ......................................................................................................... 21 
 
 
 
 
 
 
 
 
 
 
 
 
6 
 
INTRODUÇÃO 
 
Nos tempos atuais, o controle manual para organização de uma empresa no 
ramo de vendas é quase extinto, as canetas deram lugar aos teclados, as folhas de 
papel deram lugar aos monitores, não bastando, até os cálculos foram automatizados 
produzindo a vantagem de se evitar “erros humanos” e maior agilidade no 
processo de informações úteis à tomada de decisões por parte da administração, 
sabendo que cada empresa tem seu próprio sistema interno para lidar com diversos 
tipos de situações, uma simples planilha não garantiria o bom funcionamento desta e 
nem tampouco de resultados positivos a partir dela, pois a empresa poderia se 
deparar com situações específicas de sua natureza, o que origina a necessidade de 
um software exclusivo desenvolvido a partir dos requisitos que ela propõe, é isso que 
o presente projeto aborda. 
A apresentação deste projeto está subdividida em partes que detalham e 
concluem os estudos, solucionando o desafio proposto que é a exigência de se 
apresentar o levantamento e a análise de requisitos de um sistema para a plataforma 
desktop a ser utilizado em uma loja de venda de jogos eletrônicos, acessórios e 
produtos geek devendo possuir módulos de acessibilidade para que eventuais 
usuários portadores de deficiência consigam utilizá-lo. 
 
 
1. O LEVANTAMENTO E A ANÁLISE DE REQUISITOS DE UM SISTEMA 
 
Para iniciar o levantamento e a análise de requisitos de um sistema, foi 
necessário adquirir as práticas para captar e mapear necessidades das organizações 
em um mercado mais competitivo, de forma eficiente no futuro do projeto de software, 
e utilizado o paradigma da orientação a objetos, por ser mais difundido no mercado, 
no padrão da evolução voltadas para segurança e reaproveitamento de código, 
no desenvolvimento de aplicação moderna. 
Considerada a engenharia de requisitos como fase fundamental dentro do 
projeto de desenvolvimento, por especificar, implementar, validar, e implantar o 
software, a importância no relacionamento de atividade com os clientes e usuários 
7 
 
finais para descobrir o problema a ser resolvido, os serviços do sistema, o 
desempenho, restrições de hardware e outras informações. 
Com esse novo mercado a competição visa para empresa obter foco mais 
completo, na abordagem das atividades, interação profissional, relação com outra 
organização, utilização e funcionamento dos recursos físicos e sistemas 
computacionais. Para entendermos melhor essas abordagens técnicas são expostas 
através da modelagem de processos de negócio ou diagramas de processos, utilizada 
diagramas da UML (Unified Modeling Language) como ferramenta de apoio, para 
representar, modelar o sistema de software, compondo atividades das áreas de 
negócios ou da empresa, proporcionando a otimização no processo atual. 
Apesar da empresa possuir produtos no grau de raridade e disponibilidade da 
plataforma de desenvolvimento dos jogos, o foco é gerenciar as vendas efetuadas ao 
cliente. 
 
 
2. REQUISITOS DO SOFTWARE 
 
Os requisitos de um software são as condições minúsculas que o mesmo deve 
atender a fim de solucionar os problemas e, dessa forma,satisfazerem as 
necessidades do cliente contratante. No caso de um software por demanda, produto 
deste projeto, o atendimento destes requisitos e os de qualidade é o principal foco 
desta empresa no desenvolvimento do software. Para tanto, é necessário definir e 
documentar os requisitos funcionais, não funcionais e os de negócios que o software 
deve atender. 
 
 
2.1 REQUISITOS FUNCIONAIS 
 
Os requisitos funcionais são as aplicações que o software deve possuir no 
intuito de atender a demanda do cliente. É a razão de ser de um software. No nosso 
projeto, o software deve atender, a título de requisitos funcionais as seguintes 
demandas: 
 
8 
 
 Possuir um Banco de Dados no qual serão elencados todos cadastros, 
alterações, consultas e as exclusões dos produtos vendidos na loja, e os 
cadastros dos clientes, controle de acesso ao sistema com níveis de login; 
 Gerar um código único para cada item, de forma que um produto não possa ser 
emprestado para mais de um usuário ao mesmo tempo; 
 Funcionalidade para tornar indisponível qualquer produto que apresentar 
defeito ou estiver em manutenção; 
 Possuir outro Banco de Dados ao qual serão vinculados todos os usuários do 
sistema, atendentes, estoquistas e o supervisor da loja e etc. 
 
 
2.2 REQUISITOS NÃO FUNCIONAIS 
 
Os requisitos não funcionais são aqueles intrínsecos ao funcionamento do 
software em sua relação com o sistema e o hardware. Dessa forma, os requisitos não 
funcionais a serem verificados são: 
 
 O espaço que este ocupará na memória quando não executado (kbytes) e 
quando executado (RAM); 
 Sua velocidade está atrelada ao tempo de utilização da tela, ou a transações 
processadas por segundo (CODIFICAR, 2017); 
 A facilidade de utilização poder ser medida pelo número de janelas ou tempo 
de treino (CODIFICAR, 2017); 
 A confiabilidade é inerente ao tempo médio de utilização antes do sistema 
falhar, à disponibilidade ou à taxa de ocorrências de falhas (CODIFICAR, 
2017). 
 
 
2.3 REQUISITOS E REGRAS DE NEGÓCIO 
 
Os requisitos de negócio são aqueles que definem a forma como loja de venda 
de jogos eletrônicos, pretende atingir os objetivos estratégicos do negócio. Dessa 
forma, os requisitos a serem verificados são: 
9 
 
 
 Registros; 
 Relatórios; 
 Controle de fluxo; 
 Consultas; 
 Cadastros. 
 
Segundo Dextra, 2013, as Regras de Negócio definem a forma de como a 
instituição deve fazer negócio, refletindo a política interna, regras básicas de conduta, 
etc. ou seja, estipula o comportamento ao qual os usuários são submetidos dentro do 
negócio. Restrições, validações, condições e exceções do processo são exemplos 
clássicos de regras de negócio. 
A interface das regras de negócio é o ambiente no qual os usuários estão 
submetidos a tais regras. Neste caso, as atividades nas quais serão empregados os 
produtos poderão ser classificadas conforme o grau de importância ou visibilidade e 
assistência prevista para esta. Desta forma, evita o emprego do erro de busca de 
informações. Assim sendo, na tabela abaixo, será especificada a regra de negócio 
para cotar o grau de importância de cada atividade: 
 
N_Pedido C_Produto N_Produto Status Usuários 
000001 1001 Jogos1 Prior1 SUPERVISOR 
000002 1002 Jogos2 Prior2 ESTOQUISTA 
000003 1003 Jogos3 Prior3 ATENDENTE 
Tabela 1. Interface de regras de negócios – grau de importância da atividade. 
Fonte: Autor. 
 
 
3. METODOLOGIA DE QUALIDADE 
 
Os modelos de qualidade são ferramentas poderosas que auxiliam na criação 
dos fundamentos de uma empresa se software, a fim de torna-la apta a evoluir à 
medida que atinge os mais elevados graus de maturidade e, dessa forma, se 
consolidarem no mercado como empresas que gozem de pleno reconhecimento, 
confiabilidade e renome. 
10 
 
Por se tratar de uma norma nacional, a qual torna o processo de melhoria 
de qualidade adaptada à realidade local, e por se tratar de um projeto feito por 
demanda para uma instituição nacional, o modelo de qualidade a ser empregado para 
estipular o grau de maturidade da empresa e os testes a serem realizados no software 
será o de Melhoria de Processo de Software Brasileiro (MPS.BR). Segundo RIBEIRO, 
2015, o modelo MPS.BR está estruturado em 4 componentes (modelos de referência), 
7 níveis de maturidade e 19 processos, distribuídos em seus respectivos níveis. 
Os níveis de maturidade compõem um indicador de evolução da qualidade e 
permite definir o grau de maturidade o qual se encontra o modelo de qualidade da 
empresa. Os processos são os requisitos que o modelo precisa cumprir para atingir 
os níveis de maturidade imediatamente superior. Dessa forma, os processos estão 
divididos por níveis de maturidade conforme o quadro abaixo: 
 
Nível de maturidade Processos 
A - Otimizado Não há processos específicos 
B - Gerenciado 
quantitativamente 
Não há processos específicos 
C - Definido 
Gerência de decisões 
Gerência de riscos 
Desenvolvimento para reutilização 
D - Largamente definido 
Desenvolvimento de requisitos 
Projeto e construção do produto 
Integração do produto 
Verificação 
Validação 
E - Parcialmente definido 
Definição do processo organizacional 
Avaliação e melhoria do processo 
organizacional 
Gerência para reutilização 
Gerência de recursos humanos 
F - Gerenciado 
Garantia da qualidade 
Gerência da configuração 
Medição 
Aquisição 
Gerência de portifólio 
G - Parcialmente gerenciado 
Gerência de projetos 
Gerência de requisitos 
Tabela 2. Processos por níveis de maturidade. 
Fonte: RIBEIRO, 2015. 
11 
 
4. OBJETOS 
 
Um objeto é um elemento computacional que representa, no domínio da 
solução, alguma entidade (abstrata ou concreta) do domínio de interesse do problema 
sob análise. Objetos similares são agrupados em classes. No paradigma de 
orientação a objetos, tudo pode ser potencialmente representado como um objeto. 
Sob o ponto de vista da programação, um objeto não é muito diferente de uma variável 
no paradigma de programação convencional. Por exemplo, quando se define uma 
variável do tipo “int” em C ou em Java, essa variável tem: 
 
 Um espaço em memória para registrar o seu estado atual (um valor); 
 Um conjunto de operações associadas que podem ser aplicadas a ela, através 
dos operadores definidos na linguagem que podem ser aplicados a valores 
inteiros (soma, subtração, inversão de sinal, multiplicação, divisão inteira, resto 
da divisão inteira, incremento, decremento). 
 
Da mesma forma, quando se cria um objeto, esse objeto adquire um espaço 
em memória para armazenar seu estado (os valores de seu conjunto de atributos, 
definidos pela classe) e um conjunto de operações que podem ser aplicadas ao objeto 
(o conjunto de métodos definidos pela classe). Um programa orientado a objetos é 
composto por um conjunto de objetos que interagem através de "trocas de 
mensagens". Na prática, essa troca de mensagem traduz-se na invocação de métodos 
entre objetos. 
 
 
5. CLASSES 
 
O desenvolvimento de classes é o resultado da abstração. Uma vez definidos 
os devidos escopos, teremos condições de pensar em termos de classes. É fácil notar 
que muitos objetos possuem características estruturais semelhantes, embora todo 
objeto seja único. Um bom exemplo disso são os objetos que recebem a denominação 
genérica de “carro”. Todos os carros possuem uma mesma estrutura, ou seja, todos 
os objetos carro implementam os mesmos métodos e mantém informações sobre os 
mesmos atributos. O fato de que cada objeto mantém seus próprios atributos de forma 
12 
 
encapsulada confere uma identidade única a cada objeto e também permite que dois 
objetos possam, eventualmente, possuir valores iguais para seus atributos. 
Esses grupos de objetos com estruturas semelhantes são definidos em termos 
de classes. Classes consistem na unidade básica da construção de um programa 
orientado a objetos e definemo conjunto de atributos mantidos por um conjunto de 
objetos e o comportamento que esses objetos devem respeitar. 
 
Segue exemplo de uma classe: 
 
 
Figura 1. Exemplo de classe. Fonte: Autor. 
 
6. HERANÇA 
 
Herança é um conceito muito parecido com a delegação. No entanto, seu 
objetivo é a derivação de classes, ou seja, a criação de uma classe (classe filha) onde 
sua base é uma classe já existente (classe pai), sendo adicionados a essa nova classe 
apenas atributos e métodos que não existam na classe original ou a execução de um 
método que seja diferente do método da classe original. Em outras palavras, a 
herança é um mecanismo de reaproveitamento em que as classes originais ficam 
contidas na nova classe. A reutilização de classes via mecanismo de delegação é útil 
quando consideramos que a classe que reutiliza instâncias de outras classes é 
13 
 
composta destas. Um bom exemplo é a classe Data Hora, que é composta das classes 
Data e Hora. 
A solução é a reutilização de classes por meio do mecanismo de herança, no 
qual podemos criar uma classe usando outra como base e descrevendo ou 
implementando as diferenças e adições da classe usada como base, isso com a 
reutilização dos campos e métodos não privados da classe base. O mecanismo de 
herança é o mais apropriado para criar relações entre classes. 
 
Segue exemplo de herança, onde cliente e fornecedor herdam atributos de 
pessoa: 
 
 
Figura 2. Exemplo de Herança. Fonte: Autor. 
 
7. POLIMORFISMO 
 
O polimorfismo está relacionado com o conceito de herança, especificamente 
em relação a métodos. O mecanismo de herança permite a criação de classes a partir 
de outras já existentes com relações “é-um-tipo-de”, de forma que, a partir de uma 
classe genérica, classes mais especializadas possam ser criadas. Quando uma nova 
classe necessita de todos os atributos e métodos de uma já existente, porém a nova 
classe possui a execução de um ou mais métodos diferenciados, é possível 
herdarmos todos os métodos e atributos da classe original e realizar a alteração do 
comportamento do método somente na nova. O termo polimorfismo tem origem na 
composição de duas palavras gregas: Poli = muitas. Morphos = formas. Em termos 
14 
 
de programação, muitas formas significam que um único nome pode representar um 
código diferente, selecionado por algum mecanismo automático. Assim, o 
polimorfismo permite que um único nome expresse muitos comportamentos diferentes 
(SINTES, 2002, p. 122). 
 
 
8. ENCAPSULAMENTO 
 
O encapsulamento é uma das principais técnicas que define a programação 
orientada a objetos. Se trata de um dos elementos que adicionam segurança à 
aplicação em uma programação orientada a objetos pelo fato de esconder as 
propriedades, criando uma espécie de caixa preta. A maior parte das linguagens 
orientadas a objetos implementam o encapsulamento baseado em propriedades 
privadas, ligada s a métodos especiais chamados getters e setters, que irão retornar 
e inserir o valor da propriedade, respectivamente. Essa atitude evita o acesso direto a 
propriedade do objeto, adicionando uma outra camada de segurança à aplicação. 
Para fazermos um paralelo com o que vemos no mundo real, temos o 
encapsulamento em outros elementos. Por exemplo, quando clicamos no botão ligar 
da televisão, não sabemos o que está acontecendo internamente. Podemos então 
dizer que os métodos que ligam a televisão estão encapsulados. 
 
 
9. ELEMENTOS TÉCNICOS DO SISTEMA 
 
9.1 DIAGRAMA DE CLASSES 
 
Este diagrama de classe representa o usuário entrando no sistema e realizando 
o pedido, demonstrando os campos que devem ser preenchidos para concluir o 
cadastro de pedidos, apresenta os campos de cadastro das tabelas pertencentes a 
tela de cadastro de pedidos, onde é possível ver todos os campos necessários para 
completar o pedido: 
 
15 
 
 
Figura 3. Diagrama de Classes. Fonte: Autor. 
 
 
9.2 DIAGRAMA DE OBJETOS 
 
O diagrama de objetos representa um detalhamento do que é a real construção 
da marcação do pedido, é apresentado a descrição do real pedido que o sistema 
trabalha. Demonstrando os nomes que são gravados nas variáveis para consolidar a 
reserva no banco de dados: 
 
16 
 
 
Figura 4. Diagrama de Objetos. Fonte Autor. 
 
 
10. TELA DE CADASTRO 
 
A tela abaixo apresenta os perfis dos usuários, e suas atividades: 
 
 
Figura 5. Tela inicial. Fonte: Autor. 
 
 
17 
 
Selecionamos o perfil para acesso às informações, ou clicamos no Home para 
retornar na tela inicial da loja: 
 
 
Figura 6. Tela de seleção de perfil. Fonte: Autor. 
 
 
Na tela abaixo digitamos a ID e a senha, e clicamos no botão entrar para 
continuar no acesso ou sair para retornar na tela dos usuários: 
 
 
Figura 7. Tela de login. Fonte: Autor. 
18 
 
A próxima tela abaixo apresenta as opções de Cliente, Produto e Venda, após 
a identificação na tela de login. Para verificarmos cadastros, clicamos em Cliente. 
 
 
Figura 8. Tela de usuário. Fonte: Autor. 
 
Na tela Cliente, temos o botão Cadastro, Consulta, Alterar e Excluir. Para incluir 
cliente, clicamos em Cadastro; para verificar se já existe cliente, clicamos em 
Consulta; para corrigir erros ou atualizar dados do cliente, clicamos em alterar, ou 
caso haja a necessidade de excluir o cadastro de um cliente, clicamos em excluir. Se 
não houver nenhuma necessidade clicamos no botão Home para voltar na tela 
anterior. 
 
 
Figura 9. Tela Cliente. Fonte: Autor. 
19 
 
Na tela Produto, há também os botões Cadastro, Consulta, Alterar e Excluir. Se 
há necessidade de incluir produto, clicamos no Cadastro; verificar produto, clicamos 
em Consulta; corrigir erros ou atualizar dados do produto, clicamos em Alterar, ou 
caso haja a necessidade de excluir um produto, clicamos em Excluir. Se não houver 
nenhuma necessidade clicamos no botão Home para voltar na tela anterior. 
 
 
Figura 10. Tela Produto. Fonte: Autor. 
 
A tela Venda apresenta também o botão Cadastro, Consulta, Alterar e Excluir. 
Podemos incluir venda, verificar se já existe cliente, corrigir erros ou atualizar dados 
do produto, e, se houver a necessidade de cancelar a venda. 
 
 
Figura 11. Tela Venda. Fonte: Autor. 
20 
 
Observação: O cancelamento de uma venda concretizada só poderá 
executado através do perfil supervisor da loja. Caso não haja nenhuma 
necessidade, clicamos no botão Home para voltar na tela anterior. 
 
 
 
 
 
CONCLUSÃO 
 
Podemos concluir deste projeto, que uma empresa de software não se destaca 
no mercado apenas pelas inovações tecnológicas que apresenta, é imprescindível 
que essas venham ligadas à uma palavra muitas vezes oculta entre as empresas que 
não conseguem traçar seus objetivos e metas, que é a “qualidade”. Concluiu-se 
também que um sistema só é considerado eficiente desde que atenda às 
necessidades do cliente especificadas nos requisitos de negócio. 
Esse projeto ponderou a importância da evolução no mercado das empresas e 
softwares, trazendo a melhoria no atendimento aos clientes com geração de desktop, 
facilitando em agilizar o cadastro de usuários e produtos, por isso se fez necessário 
realizar um levantamento de análise de requisitos de sistemas, para obter um software 
atualizado, em cadastro de jogos, produtos geek e acessórios, e atender as 
necessidades dos usuários, aliando a necessidade do cliente à simplicidade de 
manuseio do sistema. 
Apesar a empresa possuir controle de estoque no grau raridade, o principal 
foco foi desenvolver o gerenciador em Desktop, e que tornou o processo mais rápido 
e organizado no controle de vendas e cadastro de clientes para a loja. 
 
 
 
 
 
 
 
 
21 
 
REFERÊNCIAS 
 
 
BRAGA, Pedro Henrique (org.). Teste de Software. Londres: Pearson Education, 
2016. 139 p. 
 
PRESSMAN, Roger; MAXIM, Bruce. Engenharia de Software: uma abordagem 
profissional. 8. ed. Nova Iorque: Mcgraw-hill Education,2016. 968p. Tradução AMGH 
Editora Ltda. 
 
SOMMERVILLE, Ian. Engenharia de Software. 8. ed. Londres: Pearson Education, 
2007. 568 p. 
 
CODIFICAR. O que são requisitos funcionais e não funcionais?. 2017. Disponível em 
https://codificar.com.br/requisitos-funcionais-nao-funcionais/#. Acesso em 03 de 
outubro de 2020; 
 
DEXTRA. Requisito ou Regra de Negócio?, São Paulo, 2013. Disponível em: 
https://dextra.com.br/pt/requisito-ou-regra-de-negocio/. Acesso em: 03 de outubro de 
2020. 
 
Disponível em https://www.devmedia.com.br/os-4-pilares-da-programacao-
orientada-a-objetos/9264. Acesso em: 03 de outubro de 2020. 
 
Disponível em https://www.devmedia.com.br/artigo-engenharia-de-software-4-
modelagem-de-processos-de-negocio/9880. Acesso em: 03 de outubro de 2020. 
 
 
https://codificar.com.br/requisitos-funcionais-nao-funcionais/
https://dextra.com.br/pt/requisito-ou-regra-de-negocio/
https://www.devmedia.com.br/os-4-pilares-da-programacao-orientada-a-objetos/9264
https://www.devmedia.com.br/os-4-pilares-da-programacao-orientada-a-objetos/9264
https://www.devmedia.com.br/artigo-engenharia-de-software-4-modelagem-de-processos-de-negocio/9880
https://www.devmedia.com.br/artigo-engenharia-de-software-4-modelagem-de-processos-de-negocio/9880
	INTRODUÇÃO
	1. O LEVANTAMENTO E A ANÁLISE DE REQUISITOS DE UM SISTEMA
	2. REQUISITOS DO SOFTWARE
	2.1 REQUISITOS FUNCIONAIS
	2.2 REQUISITOS NÃO FUNCIONAIS
	2.3 REQUISITOS E REGRAS DE NEGÓCIO
	3. METODOLOGIA DE QUALIDADE
	4. OBJETOS
	5. CLASSES
	6. HERANÇA
	7. POLIMORFISMO
	8. ENCAPSULAMENTO
	9. ELEMENTOS TÉCNICOS DO SISTEMA
	9.1 DIAGRAMA DE CLASSES
	9.2 DIAGRAMA DE OBJETOS
	10. TELA DE CADASTRO
	CONCLUSÃO
	REFERÊNCIAS