Documentação de um

Produto de Software

Nome do Projeto

Nome dos Alunos (G3):

RA Nome
22.00110-7 Arturo Garcia
23.00873-3 Brunno Souza
23.00771-0 Pedro Gabriel
23.01047-9 João Pedro Bluhu
23.01522-5 Matheus Passari
23.00080-5 André Martinez
 2022

Documentação de um Produto de Software – Autora do Modelo: Profa. Dra. Ana Paula Gonçalves Serra 2
 ÍNDICE DETALHADO
1. LEVANTAMENTO DOS REQUISITOS DO SISTEMA DE SOFTWARE............3
1.1. EXTRAÇÃO DE REQUISITOS...................................................................................................................3
1.2. ANÁLISE DA COLETA DE REQUISITOS...................................................................................................3
2. ESPECIFICAÇÃO DOS REQUISITOS DO SISTEMA DE SOFTWARE.............3
2.1. REQUISITOS FUNCIONAIS......................................................................................................................3
2.2. REQUISITOS NÃO-FUNCIONAIS.............................................................................................................3
3. ANÁLISE/PROJETO....................................................................................................4
3.1. DIAGRAMA DE CLASSES.......................................................................................................................4
3.2. DIAGRAMA DE SEQUÊNCIA...................................................................................................................4
3.3. MODELO DE BANCO DE DADOS............................................................................................................4
3.4. DIAGRAMA DE ATIVIDADES (OPCIONAL)..............................................................................................4
3.5. DIAGRAMA DE ESTADOS (OPCIONAL)...................................................................................................4
4. IMPLEMENTAÇÃO.....................................................................................................5
5. TESTES...........................................................................................................................5
6. RESULTADOS E CONSIDERAÇÕES.......................................................................5
APÊNDICE I.........................................................................................................................5

Documentação de um Produto de Software – Autora do Modelo: Profa. Dra. Ana Paula Gonçalves Serra 3
 0- Descrição/Resumo do Projeto :
Faremos um jogo no estilo de um jogo de tabuleiro, onde para avançar as casas o jogador deve
responder uma pergunta. As casas a serem andadas serão definidas pela jogada de um dado. As
perguntas serão divididas em três categorias, fácil, médio ou difícil, que irão influenciar na
quantidade de casas ganhas. Haverá também um adversário que competirá com o usuário, que
responderá às perguntas de forma aleatória. O tempo que o usuário demora para finalizar um jogo
será armazenado para a formação de um ranking com os melhores tempos. As perguntas serão sobre
programação em Java, Python e Banco de Dados em SQL. Usaremos a linguagem Java com
bibliotecas de interface gráfica (javax.Swing.*; java.awt.*) e outras para diversas funções
(java.util*). Integraremos a linguagem SQL para fazer o uso de banco de dados, com uma tabela para
armazenar as perguntas a serem feitas durante o jogo e outra para armazenar os dados do ranking de
melhores tempos. Utilizaremos a ferramenta Paint para desenhar os personagens.

1. Levantamento dos Requisitos do Sistema de Software

Este capítulo tem como objetivo apresentar o levantamento dos requisitos do Sistema de Software e a
forma de extração dos Requisitos.

1.1. Extração de Requisitos

As estratégias de extração de requisitos a serem utilizadas serão o

Brainstorming e entrevistas relacionadas com os professores. As
perguntas que serão realizadas são as seguintes:

1.1.1. Gerais: 
1.1.1.1. Acha viável colocar um bot para contra ou apenas ser solo 
1.1.1.2. (Se aceitar colocar o BOT) Será engraçado colocar o nome do
bot com referência de outras instituições? 
1.1.1.3. Acha mais interessante a pontuação ser por meio de pontos
de pergunta ou por meio de timer? 
1.1.2. Gameplay: 
1.1.2.1. Acha que é necessário música ou efeito sonoro? 
1.1.2.2. Tabuleiro precisa ser grande, tipo umas 32 casas ou mais? 
1.1.2.3. Ao acertar ou errar, deve ser explicado as questões ou apenas
ao errar? 
1.1.2.4. Durante o jogo, os peões devem ter animação de movimento
ou devem ser minimalistas? 

Documentação de um Produto de Software – Autora do Modelo: Profa. Dra. Ana Paula Gonçalves Serra 4
 1.1.3. Java: 
1.1.3.1. Quais as bibliotecas que devemos usar para montagem das
partes gráficas?  
1.1.3.2. O java habilita a gente fazer muitas coisas, acha que é possível
fazer mais alguma coisa? 
1.1.3.3. Será fácil randomizar uma pergunta, queremos que apareça
perguntas aleatórias e não apareça de novo? 
1.1.4. SQL: 
1.1.4.1. Será possível randomizar uma pergunta, queremos que
apareça as perguntas aleatórias? E fazer com que a pergunta
não apareça novamente 
1.1.4.2. Quantas tabelas você acha que podemos fazer? 
1.1.4.3. É possível colocar em ordem alfabética ou numérica no banco
de dados? 
1.1.5. Final:  
1.1.5.1. Acha que precisa adicionar mais alguma coisa? 

1.2. Análise da Coleta de Requisitos

Análise das entrevistas:

1.2.1. Gerais: 
1.2.1.1. Acha viável colocar um bot para contra ou apenas ser solo?
Resposta: É interessante colocar um bot pois vai tornar a
gameplay mais desafiadora.
1.2.1.2. (Se aceitar colocar o BOT) Será engraçado colocar o nome do
bot com referência de outras instituições?
Resposta: Pode ser interessante, mas é preciso ter cuidado
para não desrespeitar a instituição e professores que também
possam trabalhar lá.
1.2.1.3. Acha mais interessante a pontuação ser por meio de pontos
de pergunta ou por meio de timer?
Resposta:  Foi recomendado a utilização de um timer para
verificar quanto tempo cada jogador demorou para responder
a pergunta e pontuar os jogadores mais rápidos.

1.2.2. Gameplay: 
1.2.2.1. Acha que é necessário música ou efeito sonoro? 
Resposta: Foi recomendado a adição de efeitos sonoros para
tornar o jogo mais agradável e atraente para o jogador.
1.2.2.2. Tabuleiro precisa ser grande, tipo umas 32 casas ou mais? 
Resposta: Foi recomendado encontrar um equilíbrio para que
o jogo não fique curto e nem longo, pois curto seria ruim para
jogar e longo poderia seria entediante

Documentação de um Produto de Software – Autora do Modelo: Profa. Dra. Ana Paula Gonçalves Serra 5
 1.2.2.3. Ao acertar ou errar, deve ser explicado as questões ou apenas
ao errar? 
Resposta: Foi recomendado explicar as respostas pois, por ser
um projeto para um jogo didático, explicar os erros ajudaria no
quesito aprendizagem.
1.2.2.4. Durante o jogo, os peões devem ter animação de movimento
ou devem ser minimalistas? 
Resposta: Foi respondido que depende do estilo do jogo. Se
fizermos algo mais simples a falta de animação pode combinar
com o estilo, já se fizermos um design mais complexo as
animações seriam necessárias.

1.2.3. Java: 
1.2.3.1. Quais as bibliotecas que devemos usar para montagem das
partes gráficas?
Resposta: Foi recomendado o uso da biblioteca Java FX para
criar a parte gráfica do jogo, já que há um módulo sobre ela no
curso de Oracle disponível na disciplina de Programação
Orientada a Objetos. Também é possível fazer uso da
biblioteca Javax.swing para a interface gráfica.
1.2.3.2. O java habilita a gente fazer muitas coisas, acha que é possível
fazer mais alguma coisa? 
Resposta: A integração do Java com o SQL é muito prática e vai
facilitar bastante este processo. No geral a linguagem e suas
bibliotecas são capazes de produzir tudo que deve ser feito no
nosso projeto.
1.2.3.3. Será fácil randomizar uma pergunta, queremos que apareça
perguntas aleatórias e não apareça de novo? 
Resposta: Para fazer com que as perguntas não se repitam
durante o jogo é possível adicioná-las a uma lista e excluir
cada pergunta já feita da lista. A biblioteca Java.util.random
possibilitará a randomização das perguntas.
1.2.4. SQL: 
1.2.4.1. Será possível randomizar uma pergunta, queremos que
apareça as perguntas aleatórias? E fazer com que a pergunta
não apareça novamente 
Resposta: Através do programa em Java é possível fazer isso.
1.2.4.2. Quantas tabelas você acha que podemos fazer? 
Resposta: Uma tabela para as perguntas e outra para
armazenar os dados de cada jogador (pontuação ou tempo de
jogo).
1.2.4.3. É possível colocar em ordem alfabética ou numérica no banco
de dados?
Resposta: Sim é possível colocar em ordem alfabética usando
“ORDER BY”

Documentação de um Produto de Software – Autora do Modelo: Profa. Dra. Ana Paula Gonçalves Serra 6
 1.2.4.4. (Professor Aparecido) Podemos utilizar sua risada
característica no jogo?
Resposta: Sim, poderemos.
1.2.5. Final:  
1.2.5.1. Acha que precisa adicionar mais alguma coisa? 
Resposta: A ideia do jogo está bem completa e tudo parece ser
viável.

2. Especificação dos Requisitos do Sistema de Software

2.1. Requisitos Funcionais

3. TÍTULO  DESCRIÇÃO 

RF01 - Realizar o cadastro  Poderá se cadastrar para ter seu usuário. 

RF02 - Fazer o login  Poderá realizar o login da sua conta. 
RF03 - Entrar no menu de opções  Poderá ligar e desligar o som. 
RF04 - Fazer logout  Sairá do seu login. 
RF05 - Consulta do ranking geral  Poderá ver quais são as maiores pontuações
do jogo. 
RF06 - Jogar partida  Entrará em uma partida. 
RF07 - Escolher entre as 3 alternativas  Na pergunta aparecerá 3 alternativas,
apenas uma correta, você deverá escolher. 
RF08 - Reiniciar a partida  Poderá reiniciar toda a partida e começar do
zero. 
RF09 - Sair da partida  Poderá sair da partida e voltar para a página
inicial. 
 

Documentação de um Produto de Software – Autora do Modelo: Profa. Dra. Ana Paula Gonçalves Serra 7
Catálogo de Atores 
Aluno O ator “jogador” fará o cadastro com
nome e senha e efetuará o login no jogo.
Depois, poderá jogar uma partida e
consultar o ranking geral do jogo.
Bot O ator “bot” servirá como oponente ao
jogador. Ele jogará a partida escolhendo
alternativas de maneira aleatória.

Casos de Uso Principal

Jogar a partida
Breve descrição
Este caso de uso tem a função de começar a partida e jogá-
la, guardando seu desempenho em um ranking após o término.
Fluxo Básico
Ocorre quando o jogador seleciona a opção “Jogar” no menu
principal.

Documentação de um Produto de Software – Autora do Modelo: Profa. Dra. Ana Paula Gonçalves Serra 8
 1. O ator “Jogador” pode começar o jogo clicando em “Jogar” após
fazer o cadastro. [FA1]
2. O “Jogador” responde perguntas sobre diferentes linguagens de
programação. [FA2]
3. Ao chegar ao fim do tabuleiro, a partida se encerra e o
desempenho é salvo no ranking geral.

Fluxo Alternativo
[FA1] Fluxo Alternativo 1: Encerrar partida.
Ocorre quando o jogador decide encerrar a partida antes de seu
término.
1. O jogador clica em “Jogar”.
2. Antes de a partida acabar, o ator jogador clica em “Encerrar
partida”.
3. O fluxo retorna ao fluxo básico 1.

[FA2] Fluxo Alternativo 2: Reiniciar partida.

Ocorre quando o jogador decide reiniciar a partida durante o jogo.
1. O jogador clica em “Jogar”.
2. Antes de a partida acabar, o ator jogador clica em “Reiniciar
partida”.
3. O fluxo retorna ao fluxo básico 2.

Cadastrar
Breve descrição
Este caso tem a função de realizar o cadastro de um novo jogador
caso ele ainda não possua.
Fluxo Básico
É iniciado quando o ator “Jogador” seleciona a opção de “Realizar
cadastro”.
1. O ator “Jogador” deve informar nome e senha desejados. [FA1]
[FA2]
2. O cadastro dele é realizado no sistema.
Fluxo Alternativo
[FA1] Fluxo alternativo 1: Dados incompletos.
Esse fluxo alternativo ocorre quando algum dos dados
(nome e senha) não foram informados.
1. O sistema informa que o dado não foi inserido.
2. Retorna ao primeiro passo do Fluxo Básico.

Documentação de um Produto de Software – Autora do Modelo: Profa. Dra. Ana Paula Gonçalves Serra 9
 [FA2] Fluxo alternativo 2: Já possui cadastro.
Esse fluxo alternativo acontece caso o usuário perceba que
já possui cadastro no sistema.
1. O ator “Jogador” seleciona a opção “Já possui cadastro?”.
2. Retorna à página inicial do jogo.

3.1. Requisitos Não-Funcionais

RNF01 - Estética de interface com o usuário. Deve ser atrativo, dinâmico e intuitivo. 
RNF02 - Confiabilidade  Deve sempre manter o progresso do usuário
salvo e atualizado no banco de dados. 
RNF03 - Integridade  As informações não podem ser alteradas
sem que seja no perfil do próprio jogador. 
RNF04 - Usabilidade  O jogo deve ser rápido e não travar. 
RNF05 - 3 níveis de dificuldades  Todas as perguntas terão 3 níveis de
dificuldades (Fácil, Médio, Difícil), sendo que
cada uma acontece um certo movimento 
RNF06 - Bot como adversário  Será jogado contra um bot que jogará
aleatoriamente. 
RNF07 - Layout da partida  Jogo será composto por tabuleiro e 2 peões
(Jogador e Bot), arquivo PNG. 

3. Análise/Projeto

3.1. Diagrama de Classes

Neste item deve ser apresentado o modelo do domínio, visão de negócio, que representa um primeiro
modelo conceitual do diagrama de classes.
O diagrama de classes deve possuir todas as classes identificadas do sistema, deve conter os atributos
e métodos de cada classe, e os relacionamentos entre elas.
Disciplina de Apoio: Modelagem Orientada a Objetos.

3.2. Diagrama de Sequência

Neste item deve ser apresentado os diagramas de sequência com maior valor de negócio ao sistema.
A escolha é realizada por caso de uso. Não há necessidade de realizar o diagrama de sequência para
<<crud>>.

Documentação de um Produto de Software – Autora do Modelo: Profa. Dra. Ana Paula Gonçalves Serra 10
 Disciplina de Apoio: Modelagem Orientada a Objetos.

3.3. Modelo de Banco de Dados

Neste item deve ser apresentado o modelo lógico relacional de banco de dados como proposta de
solução.
Também deve ser representado o link de acesso ou repositório dos scripts físicos de banco de dados.
Disciplina de Apoio: Banco de Dados Relacional.

3.4. Diagrama de Atividades (opcional)

O diagrama de atividades representa o detalhamento de tarefas e o fluxo de uma atividade para outra
de um sistema, geralmente utilizado para os métodos que contém regras de negócio.
Esse diagrama deverá ser elaborado se houver necessidade e agregar valor ao projeto.
Disciplina de Apoio: Modelagem Orientada a Objetos.

3.5. Diagrama de estados (opcional)

O diagrama de estados especifica as sequências de estados pelas quais o objeto pode passar durante
seu ciclo de vida em resposta a eventos.
Disciplina de Apoio: Modelagem Orientada a Objetos.

4. Implementação
Neste item indicar o link de acesso ou repositório de toda implementação de programação orientada a
objetos Java e Python (opcional).
Disciplina de Apoio: Programação Orientada a Objetos, Lógica de Programação e Banco de Dados
Relacional.

5. Testes
Neste item indicar o link de acesso ou repositório de todas as evidências de testes unitários realizados no
projeto, de acordo, com os casos de uso especificados.
Disciplina de Apoio: Programação Orientada a Objetos.

6. Resultados e Considerações

Documentação de um Produto de Software – Autora do Modelo: Profa. Dra. Ana Paula Gonçalves Serra 11
 Neste item devem ser apresentados os principais “prints” das telas do sistema de software desenvolvido,
com uma breve explicação de cada tela e ao final as considerações gerais do projeto, sob o ponto de vista
dos requisitos que foram implementados e os resultados obtidos.

Apêndice I
Neste item deve ser anexado o roteiro de entrevista ou questionário respondido.
Disciplina de Apoio: Modelagem Orientada a Objetos.

Documentação de um Produto de Software – Autora do Modelo: Profa. Dra. Ana Paula Gonçalves Serra 12