PIM VI

Prévia do material em texto

23
UNIP EaD
Projeto Integrado Multidisciplinar
Curso Superior de Tecnologia em
Análise e Desenvolvimento de Sistemas
NOME:		RA:
NOME:		RA:
Levantamento e análise de requisitos de um sistema de controle de vendas de uma loja de jogos, acessórios e produtos geek
São Paulo
2022
NOME:		RA:
NOME:		RA:
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 apresentado ao curso de Análise e Desenvolvimento de Sistemas como requisito para aprovação no semestre, sob orientação do professor(a):
São Paulo
2022
RESUMO
O Projeto Integrado Multidisciplinar(PIM) consiste em um projeto que estimula o desenvolvimento da capacidade do aluno em utilizar a devida instrumentação teórico-prática, que lhe permita intervir no ambiente das organizações com decisões acertadas. Por meio do PIM, o aluno é capaz de desenvolver o método científico e treinar suas habilidades de leitura, interpretação de dados e escrita. O Objetivo deste PIM VI é apresentar o levantamento e a análise de requisitos de um sistema de controle de vendas de uma loja de jogos, acessórios e produtos geek. Os objetivos específicos são: Desenvolver e aplicar os conhecimentos adquiridos durante o curso das disciplinas de: Análise de Sistemas Orientada a Objetos, Banco de Dados e Gestão Estratégica de Recursos Humanos; exercitar metodologias e técnicas de análise utilizadas para o desenvolvimento de sistemas em computador; desenvolver análise de sistemas orientada a objetos, explorar e utilizar ferramentas computacionais para modelagem de negócios; desenvolver técnicas usadas na produção de artefatos UML, argumentar e discutir requisitos funcionais e não funcionais, usabilidade e aplicação de normas e ainda fomentar o hábito de trabalho em equipe e execução de projetos envolvendo múltiplas disciplinas. Pode-se dizer que os objetivos gerais e específicos do Projeto Integrado Multidisciplinar foram alcançados e que seus resultados proporcionam crescimento acadêmico e profissional aos seus autores.
Palavras-chave: Análise de sistemas. Análise de requisitos. Banco de dados. Estratégia de Recursos Humanos.
ABSTRACT
The Integrated Multidisciplinary Project (PIM) is a work proposed by UNIP as a way of uniting theoretical and practical contents in a way that makes the best use of the bimester subjects. The objective of this PIM VI is to present the survey and analysis of requirements for a sales control system for a game store, accessories and geek products. As specific objectives we have: Develop and apply the knowledge acquired in class: Object-Oriented Systems Analysis, Database and Strategic Management of Human Resources, exercise methodologies and analysis techniques used for the development of computer systems, develop analysis of object-oriented systems, explore and use computational tools for business modeling; develop techniques used in the production of UML artifacts, argue and discuss functional and non-functional requirements, usability and application of standards, and also foster the habit of teamwork and project execution involving multiple disciplines. It can be said that the general and specific objectives of the Integrated Multidisciplinary Project were achieved and that its results provide academic and professional growth to its authors.
Keywords: Systems analysis. requirements analysis. Database. Human Resources Strategy.
SUMÁRIO
INTRODUÇÃO	6
1.	ANÁLISE DE SISTEMAS ORIENTADA A OBJETOS	7
1.1	Levantamento de Requisitos	7
1.2	Análise de requisitos	8
1.3	Documentação de Requisitos	8
2.	REGRAS DE NEGÓCIO	10
2.1	Acesso ao sistema	10
2.2	Dados necessários para cadastrar um usuário	10
2.3	Acesso e navegação no Sistema	11
3.	CONTEXTO DE USO	12
3.1	Especificação dos usuários	12
3.2	Especificação de ambientes	12
3.3	Especificação de equipamento	13
3.4	Especificação de tarefas	13
4.	MODELAGEM DE CASOS DE USO	14
4.1	Descrição de casos de uso	15
4.1.1 Caso de Uso: realizar login	15
4.1.2 Caso de Uso: Realizar Cadastro:	15
4.1.3 Caso de uso: Alterar informações pessoais	16
4.1.4 Caso de uso: Verificar Login	17
4.1.5 Caso de uso: Consultar estoque	17
4.1.6 Caso de uso: Incluir Produtos no Estoque	18
4.1.7 Caso de uso: Incluir Venda	19
5.	DIAGRAMA DE CLASSE	20
6.	MODELO DE ENTIDADE- RELACIONAMENTO (MER)	21
6.1	Modelo de dados	21
7.	CONCLUSÃO	22
REFERÊNCIAS	23
INTRODUÇÃO
A fim de atender as exigências acadêmicas necessárias para o aprofundamento do conteúdo ministrado durante o período das disciplinas de Análise de Sistemas Orientada a Objetos, Banco de Dados e Gestão Estratégica de Recursos Humanos, este trabalho terá como objetivo principal proporcionar aos alunos um Outubror entendimento do ensinamento teórico estudado, promovendo a interdisciplinaridade, conhecimento e aprofundamento no ambiente organizacional e corporativo, o aprendizado de estratégias de planejamento e consequente união teórico-prática de forma a resultar em mudança positiva na compreensão do conteúdo.
Uma loja especializada em venda de jogos eletrônicos, acessórios e produtos geek contratou uma empresa para desenvolver um software de controle e gerenciamento de vendas de produtos e acessórios na área de jogos e cultura geek. Antes do Software, toas as tarefas de gerenciamento da loja eram realizadas por meio de planilhas no programa Microsoft Excel. O grupo de autores deste PIM agirá como uma fábrica de Software que foi contratada para desenvolver um sistema desktop e assim atender ao desejo do cliente, que é de um sistema para a plataforma desktop que possua módulos de acessibilidade caso hajam eventuais usuários portadores de deficiência.
 Assim, o objetivo geral deste trabalho é apresentar o levantamento e a análise de requisitos de um sistema de controle de vendas para esta loja, com base no conteúdo aprendido durante o curso das disciplinas base deste PIM, e as exigências do manual da atividade. Nas seções seguintes o trabalho será detalhado conforme tais exigências.
1. ANÁLISE DE SISTEMAS ORIENTADA A OBJETOS
Na engenharia de sistemas e engenharia de software, a análise de requisitos abarca a investigação definição e escopo de sistemas em criação ou alteração. A análise de requisitos é uma fase importante quando se está projetando um sistema, e nela o desenvolvedor identifica o que o cliente quer, suas necessidades ditas ou não, bem como o que considera imprescindível naquele sistema. Quando se identifica os requisitos é muito mais fácil projetar soluções (MACÊDO, 2012). 
Os requisitos para o sistema englobam ainda as funções que o cliente e o desenvolvedor decidiram em reunião prévia que o sistema deve realizar, assim como suas restrições e circunstâncias nas quais irá operar. Por ser tão importante é que a análise de requisitos é realizada logo no início, o que dará a direção de todo o processo e durante esta fase os desenvolvedores devem realizar um estudo aprofundado dos dados levantados a fim de construir modelos representativos como diagramas de casos de uso, diagramas de atividades, etc. do sistema que se pretende desenvolver (neste caso um sistema de gerenciamento da loja de artigos geek), validando assim as necessidades verdadeiras dos clientes.
Segundo Macêdo (2012), geralmente os requisitos são classificados em requisitos funcionais e não funcionais, onde os funcionais integram o sistema, com o objetivo de “facilitar a vida” do usuário. Em linhas gerais, os requisitos funcionais mostram quais funcionalidades um sistema deve ter e como deve responder a certas situações. Já os requisitos não-funcionais estão mais relacionados ao ambiente externo ao sistema, requisitos externos importantes para que o sistema funcione bem, como bons servidores, um firewall, etc. 
Os processos de engenharia de requisitos podem ser compostos pelas seguintes atividades: 
1.1 Levantamento de Requisitos
O levantamento de requisitos é uma fase importante e nela a equipe desenvolvedora, usuários e clientes são identificados e trabalhamjuntos a fim de entender o software como um todo, o que se quer com aquele projeto, seus requisitos funcionais e não-funcionais, etc. Esta etapa pode ser facilitada por algumas técnicas que visam recolher do cliente as informações necessárias de forma completa, a saber:
· Entrevistas não estruturadas: são aquelas sem um roteiro pré-definido, costumam ocorrer em forma de conversa.
· Entrevistas estruturadas: com um roteiro definido, a chance de não “deixar nada para trás é Outubror”.
· Observação do comportamento: Observar os usuários em seu ambiente de trabalho para perceber falhas que o programa pode sanar e funções que pode agregar;
· Aprendizagem com o usuário: A partir da conversa inicial com o usuário, o desenvolvedor pode entender e analisar como será feito o trabalho; 
· Prototipagem: É o ato de desenvolver um modelo simulando o programa real e ajuda a perceber pontos de melhoria.
· Brainstorming: Ouvir ideias de todos os envolvidos pode ser de grande valia. 
· Análise de textos: Descrição das necessidades do usuário feita em forma de texto. 
· Reutilização de requisitos: Ocorre quando se reaproveita padrões ou requisitos de sistemas já existentes. 
1.2 Análise de requisitos
Tem como objetivo o estabelecimento de um conjunto de requisitos consistentes e não ambíguos, acordado entre equipe e clientes, a partir do qual o software será desenvolvido. 
1.3 Documentação de Requisitos
Na documentação de requisitos os resultados destes processos são apresentados em um ou mais documentos compostos pelos requisitos de software. No caso do Software para o cliente deste projeto, os principais requisitos não-funcionais estão especificados no quadro 1:
Quadro 1: Requisitos não-funcionais do sistema
	Identificador
	Categoria
	Nome
	Descrição
	RNF01
	Desempenho
	Velocidade de processo
	O tempo de execução dos processos do sistema deve ser curto.
	RNF02
	Desempenho
	Atualização das vendas e estoque
	Devem ser atualizados em tempo real quando uma venda for realizada.
	RNF03
	Desempenho
	Volume de utilização
	O sistema deve poder suportar o lançamento simultâneo, caso hajam vendas simultâneas.
	RNF04
	Segurança
	Autenticação do Usuário
	Os funcionários responsáveis pelas vendas e estoque devem ter cadastro para acesso ao sistema e em caso de primeiro acesso o funcionário deve ser direcionado para efetuar seu cadastro.
	RNF05
	Segurança
	Criptografia de senhas
	Todas as senhas de usuário devem ser criptografadas ao serem armazenadas no banco de dados.
	RNF06
	Usabilidade
	Fácil utilização
	Um funcionário recém-treinado deve ser capaz de registrar uma venda e identificar saídas e entradas no estoque.
	RNF07
	Usabilidade
	Design Responsivo
	A interface gráfica do sistema deverá ter um design leve e responsivo para o uso em dispositivos diversificados com acesso à internet.
	RNF08
	Externo
	Ligação com o sistema de vendas
	Após a realização de uma venda no caixa, o sistema deve receber a baixa no estoque automaticamente.
Fonte: autores
2. REGRAS DE NEGÓCIO
2.1 Acesso ao sistema
O acesso ao sistema será feito por Login e Senha. Antes de entrar o usuário deverá realizar um cadastro, no caso de ser seu primeiro acesso. Se esquecer a própria senha, deverá clicar em link específico para solicitar uma senha temporária, e após recebe-la por e mail, efetuará Login e mudará sua senha novamente. 
2.2 Dados necessários para cadastrar um usuário
O quadro 2 apresenta os dados necessários para cadastrar um usuário no sistema, bem como as especificações para que o cadastro possa ser feito: 
Quadro 2: dados necessários para cadastro
	Dados
	Especificações
	Código
	Gerado automaticamente ao iniciar cadastro, será composto de cinco números em ordem crescente de cadastro
	Nome
	Deverá ter no máximo 70 caracteres, permitindo apenas caracteres alfabéticos. Este dado é de preenchimento obrigatório.
	CPF
	Deverá conter no máximo 11 caracteres. Não é permitida a utilização de pontos e este dado é de preenchimento obrigatório.
	RG
	Quantidade máxima de 10 caracteres alfanuméricos. Este dado é de preenchimento obrigatório.
	Data de Cadastro
	Quantidade máxima de 10 caracteres, contando com as barras divisoras de dia/mês/ano no seguinte formato: DD/MM/AAAA.
	Telefone
	Quantidade máxima de 12 caracteres, permitindo apenas números. Este dado é de preenchimento obrigatório.
	Endereço
	Quantidade máxima de 150 caracteres, permitindo apenas caracteres alfanuméricos. Este dado é de preenchimento obrigatório.
	Senha
	Deve conter pelo menos 08 caracteres, permitindo caracteres alfanuméricos e símbolos (@#$%&*_)
	Email
	Deve pertencer a um servidor válido e para finalizar o cadastro o usuário receberá uma confirmação de email no endereço fornecido. O e mail é que, juntamente com a senha escolhida serão os dados utilizados para Login.
Fonte: autores
2.3 Acesso e navegação no Sistema
Depois da validação dos dados de Login (se houver erro por duas vezes seguidas haverá a validação de um captcha), o usuário poderá clicar em produtos de seu interesse, que estarão disponíveis em prateleiras virtuais de acordo com a sua disponibilidade no sistema de controle de estoque. Este sistema é o que dará o retorno a respeito da disponibilidade ou não do produto procurado pelo cliente. Já o controle do estoque é gerenciado pelos funcionários responsáveis por meio de um sistema interno de estoque. 
3. 
CONTEXTO DE USO
3.1 Especificação dos usuários
Quadro 3: Características dos usuários aptos
	Atributo
	Requisito
	Habilidades e conhecimentos
	
	Experiência no produto
	Uso de planilhas ou outros meios de controle de venda e estoque
	Conhecimento do Sistema
	O suficiente para realizar as inclusões e exclusões necessárias
	Experiência na Tarefa
	Não requerido
	Experiência organizacional
	O suficiente para entender o fluxo dos processos.
	Treinamento
	Mínimo de 4h de treinamento
	Habilidades no teclado
	Uso de teclado do computador
	Habilidades no mouse
	Uso de Mouse do computador
	Qualificações
	Não requerido
	Habilidade Linguística
	No mínimo Intermediário (Lê bem, escreve bem, fala razoavelmente o Português).
	Atributos físicos
	
	Visão
	Visão normal ou corrigida, medida através do teste padrão.
	Audição
	Não requerido
	Destreza Manual
	Ambas as mãos com destreza normal ou apenas uma mão que utilizará teclado e mouse
Fonte: Autores
3.2 Especificação de ambientes
Com relação aos ambientes, as seguintes conexões devem estar disponíveis: Ponto de Acesso à internet (WiFi, 3G, 4G, Banda Larga, entre outros). Para ter boa usabilidade, o sistema deverá ser utilizado em um ambiente ergonômico segundo as seguintes especificações: ISO 9241-5 (Layout do posto de trabalho e requisitos de postura) e ISO 9241-6 (Requisitos de ambiente).
3.3 Especificação de equipamento
O dispositivo de acesso deve ter acesso à internet e ser capaz de apresentar por meio do seu layout a interface do sistema, seja em notebooks, tablets ou computadores desktop. Apesar de poder ser executado em celulares, existe a chance da desconfiguração de tela e dificuldade em visualizar os dados, sendo, portanto, não recomendável o uso por meio de smartphones.
3.4 Especificação de tarefas
O principal objetivo do sistema é permitir que o usuário acesse uma lista dos produtos que foram vendidos na loja e dos produtos que ainda estão em estoque, bem como as quantidades exatas de cada produto no estoque. Os objetivos secundários são o cadastro de novos produtos, acesso (login) de usuário cadastrado, consulta de produtos (por nome ou marca) e visualização do estoque geral e por produto.
4. MODELAGEM DE CASOS DE USO
Os casos de uso têm como objetivo descrever o uso e as funcionalidades do sistema. Esta descrição é realizada por meio de uma sequência definida das ações que o sistema executará e que gerará um resultado observável por um ator, seja o cliente, o programador, um analista de sistema, etc. 
Os casos de uso auxiliam a troca de informações entre analistas e clientes, descrevendo um cenário que mostra as funções do sistema do ponto de vista de quem fará a utilização,sem a necessidade de detalhar as funções internas do mesmo sistema. Os casos de uso são representados em um diagrama e os diagramas de caso de uso são representados por atores, associações e generalizações, casos de uso e relacionamento entre elementos. 
Como dito anteriormente, os atores são aqueles que interagem de alguma maneira com o sistema e são representados pelo desenho de um boneco palito enquanto um caso de uso mostra o comportamento exterior deste mesmo sistema e é representado por uma elipse e os relacionamentos são representados por traços. A Figura 1 apresenta o diagrama de casos de uso para este projeto.
Figura 1: Diagrama de casos de uso
Fonte: Autores
4.1 Descrição de casos de uso
4.1.1 Caso de Uso: realizar login
Identificação: Realizar Login
Escopo: Sistema para Loja de produtos Geek
Descrição do Propósito: Permite ao usuário entrar em sua conta
Ator primário: Dono do negócio e funcionário
Interessados: Dono do negócio + responsável pela manutenção do sistema
Pré condições: O usuário criar login e senha
Pós condições: Após realizar login o usuário é direcionado à tela de opções.
Fluxo normal:
1- O usuário acessa a URL do Sistema
2- O programa mostra um textosolicitando dados de acesso
3- Usuário clica em efetuar login
4- Usuário informa dados de acesso
5- O programa mostra texto de boas vindas e direciona o usuário para a tela de opções.
Fluxo alternativo: 
2.1- O usuário não possui cadastro e precisa se cadastrar primeiro
2.2- Extensão para efetuar cadastro 
4.1- Dados incorretos são inseridos e um texto de aviso aparece
4.1.2 Caso de Uso: Realizar Cadastro:
Identificação: Realizar Cadastro
Escopo: Sistema para Loja de produtos Geek
Descrição do Propósito: Permite ao usuário cadastrar-se no sistema
Ator primário: Funcionário da Loja
Interessados: Dono do negócio e funcionário
Pré condições: Não ser usuário cadastrado nem estar logado em alguma conta
Pós condições: Usuário é cadastrado e se torna apto a realizar Login
Fluxo Normal:
1- O programa mostra os dados necessários para a realização de cadastro.
2- O usuário preenche os dados e clica em cadastrar
3- Aparece: “Cadastro efetuado com sucesso” na tela e realiza o login do usuário, redirecionando-o para a tela de opções.
Fluxo Alternativo:
2.1 Preenchimento incorreto de dados ou campos em branco geram um texto de aviso.
2.2 Preenchimento de dados já cadastrados geram um texto de aviso.
4.1.3 Caso de uso: Alterar informações pessoais
Identificação: Alterar informações cadastradas
Escopo: Sistema para Loja de produtos Geek
Descrição do Propósito: Permite ao usuário alterar informações pessoais
Ator primário: Funcionário da Loja
Interessados: Funcionário da Loja
Pré condições: Possuir cadastro no sistema
Pós condições: Após realizar alteração o sistema salva as alterações e o usuário é direcionado à tela de opções.
Fluxo normal:
1- Acessar as informações pessoais
2- Clicar em “editar”
3- O programa mostra os campos possíveis de serem editados.
4- O usuário edita as informações desejadas e clica em “salvar”
Fluxo Alternativo:
4.1 Informações incorretas ou campos em branco geram um texto de aviso.
4.1.4 Caso de uso: Verificar Login
Identificação: Verificar Login
Escopo: Sistema para Loja de produtos Geek
Descrição do Propósito: Permite ao usuário averiguar se está logado
Ator primário: Sistema
Interessados: Sistema
Pré condições: O usuário solicita acesso a uma tela restrita
Pós condições: Os parâmetros de Login são atendidos e o usuário acessa a tela solicitada.
Fluxo Normal:
1- O usuário acessa uma tela que requer login
2- O sistema averigua se as informações de Login passam pelo Cache do sistema
3- O sistema abre a página solicitada
Fluxo Alternativo:
2.1 Se o usuário não estiver logado um texto de aviso aparece e este é redirecionado para a tela de Login.
4.1.5 Caso de uso: Consultar estoque
Identificação: Consultar estoque
Escopo: Sistema para Loja de produtos Geek
Descrição do Propósito: Permite ao usuário averiguar entradas e saídas de produtos do estoque
Ator primário: Funcionário da loja
Interessados: Dono do negócio, funcionário e cliente
Pré condições: Estar Logado no Sistema
Pós condições: O Sistema informa se o produto está disponível ou indisponível na loja.
Fluxo Normal: 
1- Usuário acessa a tela de opções
2- Inclusão para verificar Login
3- Usuário Clica em Consultar estoque
4- Usuário digita o nome do produto
5- O programa mostra o nome e imagem do produto com a informação de disponibilidade ou não.
Fluxo alternativo:
4.1 Se aquele produto não for comercializado na loja, não existirá no sistema e um texto de aviso aparecerá na tela. O mesmo ocorrerá se o nome for digitado incorretamente.
4.1.6 Caso de uso: Incluir Produtos no Estoque
Identificação: Incluir produtos no estoque
Escopo: Sistema para Loja de produtos Geek
Descrição do Propósito: Permite ao usuário incluir novos produtos ao catálogo do estoque no sistema.
Ator primário: Funcionário da loja
Interessados: Dono do negócio, funcionário e cliente
Pré condições: Estar Logado no Sistema
Pós condições: O produto é cadastrado e pode ser buscado dentro do catálogo do estoque.
Fluxo Normal:
1- O programa mostra os dados necessários para a realização da inclusão de produtos no estoque.
2- O usuário preenche os dados e clica em “incluir”.
3- Aparece na tela: “ inclusão efetuada com sucesso” .
Fluxo Alternativo:
2.1 O Preenchimento incorreto de dados ou campos em branco geram um texto de aviso.
2.2 A tentativa de inclusão de produtos já existentes no cadastro de estoque geram um texto de aviso.
4.1.7 Caso de uso: Incluir Venda
Identificação: Incluir registro de saída de produto do estoque a partir da venda
Escopo: Sistema para Loja de produtos Geek
Descrição do Propósito: Permite ao usuário dar baixa de produto do estoque automaticamente a partir de uma venda.
Ator primário: Funcionário da loja
Interessados: Dono do negócio e funcionário
Pré condições: O produto ser vendido e seu código registrado no sistema de vendas
Pós condições: Após a venda o produto de mesmo código de barras é automaticamente baixado do estoque.
Fluxo Normal:
1- Uma venda é realizada no caixa
2- O código de barras do produto vendido é reconhecido pelo sistema.
3- O produto passa a constar como “indisponível”
Fluxo Alternativo:
2.1 Produtos cadastrados incorretamente podem não ser computados corretamente.
5. DIAGRAMA DE CLASSE
As classes são representadas por retângulos que podem ser divididos em: nome da classe (acrescentado na parte superior do retângulo), atributos de classe (acrescentado no meio do retângulo) e métodos de classe (na parte de baixo do retângulo). Já os objetos da classe podem ser de três grupos: fronteira, classe de entidade e classe de controle, sendo representados pelas letras BCE inseridas em um diagrama de classes entre sinais de “menor que” e “Outubror que”. A figura 2 Apresenta o diagrama de classes de análise para este projeto.
Figura 2: Diagrama de classes de análise
Fonte: autores
6. MODELO DE ENTIDADE- RELACIONAMENTO (MER)
O Modelo Entidade Relacionamento (também chamado Modelo ER ou MER), é um modelo muito utilizado na Engenharia de Software quando se deseja detalhar as entidades envolvidas em um domínio de negócios, bem como seus atributos e como estes atributos se relacionam. Geralmente este modelo faz uma representação abstrata da estrutura que o banco de dados possuirá. Assim, o banco de dados da aplicação pode ter como conteúdo entidades como chaves e tabelas intermediárias, que apenas fazem sentido quando se fala em bases de dados relacionais.
6.1 Modelo de dados
A figura 3 Apresenta o modelo de dados para este projeto:
Figura 3: Modelo de dados
Fonte: autores
7. CONCLUSÃO
O objetivo deste trabalho foi analisar e realizar o levantamento de requisitos a fim de desenvolver um sistema para uma loja de produtos Geek, auxiliando assim no controle de vendas e estoque da loja. Os conhecimentos adquiridos nas disciplinas de Análise de Sistemas Orientada a Objetos, Banco de Dados e Gestão Estratégica de RH auxiliaram no desenvolvimento do trabalho ena união bem sucedida entre a teoria estudada e a prática do desenvolvimento desta ideia de aplicação.
A conclusão do projeto deixou clara a importância de analisar profundamente os requisitos do sistema antes de iniciar o desenvolvimento para que em posse do real desejo do cliente a aplicação possa ser desenvolvida da melhor forma possível. Assim, com o auxílio das disciplinas base e conforme o que foi solicitado no manual desta atividade foi realizada a análise e levantamento de requisitos do sistema solicitado, bem como a elaboração e a documentação por meio de diagramas e informações que podem ajudar no desenvolvimento de sistemas para que se pense a análise com vistas a um melhor aproveitamento do sistema, boa usabilidade e, consequentemente, a satisfação do cliente.
Por tudo o que foi dito, pode-se dizer que os objetivos deste PIM foram alcançados e que os alunos autores se sentem aptos a fazer uma boa análise de requisitos em futuros projetos profissionais.
REFERÊNCIAS
MACEDO, D.: Levantamento e análise de requisitos. Disponível em: <https://www.diegomacedo.com.br/levantamento-e-analise-de-requisitos/#>. Acesso em 27 de Outubro de 2022.
DEVMEDIA. MER e DER: Modelagem de Bancos de Dados. Disponível em: <https://www.devmedia.com.br/mer-e-der-modelagem-de-bancos-de-dados/14332>. Acesso em: 27 de Outubro de 2022.
FURLAN, J.: Modelagem de objetos através da UML. Editora Makron Books.
MENDES, R. UML: COMPOSIÇÃO X AGREGAÇÃO. Disponível em: <http://imasters.com.br/artigo/18901/uml/uml_composicao_x_agregacao/>. Acesso em 20 de Outubro de 2022.
IBM: Diagrama de classes. Disponível em : <https://www.ibm.com/docs/pt-br/rsas/7.5.0?topic=structure-class-diagrams>. Acesso em 27 de Outubro de 2022