Ir para o conteúdo

Especificação de Requisitos e Priorização

Este documento apresenta a consolidação dos requisitos levantados durante os 5 dias de Design Sprint. A fundamentação para esta etapa baseia-se na distinção clássica proposta por (Sommerville (2011)), que divide as necessidades do sistema em duas frentes:

  • Requisitos Funcionais: que descrevem o que o sistema deve fazer e as funções específicas, entradas e saídas que o software deve processar (Sommerville, seção 4.1.1).

  • Requisitos Não Funcionais: que, embora não descrevam serviços específicos, impõem restrições críticas às propriedades emergentes do sistema, como desempenho, confiabilidade e proteção, sendo muitas vezes mais vitais para a utilidade do software do que funções isoladas (Sommerville, seção 4.1.2).

Requisitos Funcionais

ID Nome Descrição Prioridade Rastreabilidade
RF01 Movimentar o avatar O sistema deve processar entradas WASD para deslocar o avatar 2D pelo mapa. Must aqui
RF02 Exibir resíduos O sistema deve permitir a visualização de objetos coletáveis (lixo) distribuídos no mapa. Must aqui
RF03 Coletar itens O sistema deve remover o objeto do cenário e adicioná-lo ao inventário após ação/colisão do avatar. Must aqui
RF04 Animar coleta (on click) O sistema deve acionar a animação de coleta do avatar ao clicar/interagir com um item coletável. Must aqui
RF05 Processar depósito/reciclagem O sistema deve validar a proximidade à maquininha de reciclagem para processar e transformar itens do inventário. Must aqui
RF06 Sistema de craft O sistema deve criar novos itens (úteis ou decorativos) a partir de combinações de materiais segundo receitas predefinidas, descontando-os do inventário. Must aqui
RF07 Gerir progresso O sistema deve gerenciar a transição entre as fases de limpeza, replantio e reconstrução do cenário conforme o avanço do jogador. Should aqui
RF08 Desbloquear recursos O sistema deve apresentar progressão baseada em desbloqueio de novos itens, receitas e áreas do mapa. Must aqui
RF09 Utilizar ferramentas O sistema deve permitir uso de ferramentas (machado, picareta, pá) com animação própria acionada por botão, independente do sprite do avatar. Must aqui
RF10 Posicionar objetos no mapa O sistema deve permitir ao jogador posicionar itens decorativos ou funcionais em células habilitadas do grid do mapa. Must aqui
RF11 Sistema de plantação O sistema deve permitir agricultura em grid: o avatar rega as plantações com ferramenta, com área de irrigação inicial de 1 célula. Should aqui
RF12 Tela inicial O sistema deve exibir tela inicial com as opções "Iniciar" e "Sair" (save não está no escopo do protótipo). Must aqui
RF13 Animação do avatar O sistema deve apresentar sprites distintos para os estados: andando, coletando (agachado) e segurando objeto acima da cabeça. Must aqui
RF14 Música por cenário O sistema deve suportar trilha ou efeitos sonoros por cenário para aumentar a imersão do protótipo. Could aqui
RF15 Construções simples O sistema deve permitir construções simples como casa ou moinho. Should aqui
RF16 Sistema de combate O sistema de combate deve ser considerado apenas como incremento de escopo futuro, em baixa prioridade. Could aqui
RF17 Múltiplos mapas O sistema deve suportar múltiplos mapas apenas como expansão de escopo, em baixa prioridade. Could aqui
RF18 Missões complexas O sistema deve incluir missões complexas apenas como incremento de escopo futuro. Could aqui
RF19 Sistema de mercado/guilda O sistema deve incluir mercado ou guilda apenas como funcionalidade extra de baixa prioridade. Could aqui
RF20 Tamanho do inventario Inventário deve conter 8 espaços na barra fixa e 16 na mochila, totalizando 24 espaços. Must aqui
RF21 Acumulho de itens no inventario Cada item pode acumular até 12 unidades por espaço. Must aqui
RF22 quantidade de itens A quantidade de cada item deve ser exibida dentro do quadrado correspondente no inventário. Must aqui
RF23 Loja O sistema deve possuir um sistema de compra e venda de itens disponivel Must Aqui
RF24 Compra e venda O sistema de loja deve aceitar a compra de materias adquiridos durante o gameplay do jogo e oferecer sementes para o plantio Must aqui
RF25 Agricultura As sementes so podem ser plantadas em terreno arado Should aqui
RF26 Reguador Se uma semente não for regada, seu cressimento (mudança de sprite) não acontece Should aqui
RF27 Cresimento Caso seja molhada todos so dias, a planta em 4 ciclos chegara em sua forma final Should aqui
RF28 Sono Quando o protagonista entrar em sua casa um dia se passa, fazendo plantas cresserem e mais lixo aparecer Could aqui
RF29 Venda O jogador pode vender suas plantas cultivadas e lixos para a loja conseguindo dinheiro Must aqui
RF30 Dinheiro Ao vender itens o jogador ganha certa quantia de dinheiro que pode ser usado na propia loja Must aqui

Requisitos Não Funcionais

ID Nome Descrição Tipo Prioridade Rastreabilidade
RNF01 Plataforma de implementação O sistema deve ser desenvolvido na engine Godot, escolhida pela simplicidade de uso e suporte nativo a jogos 2D. Desenvolvimento Must aqui
RNF02 Estética visual pixel art Os sprites devem ser criados manualmente no Piskel, em estilo Pixel Art de baixa resolução, sem uso de geração por IA. Ético Must aqui
RNF03 Grid-based O mapa deve ser dividido em células quadradas de tamanho definido, servindo de base para posicionamento de sprites e lógica de interação. Desenvolvimento Must aqui
RNF04 Prototipagem iterativa O protótipo deve ser entregue como demo em vídeo (produzido no After Effects e Premiere) acompanhado de uma página HTML de apresentação do projeto. Desenvolvimento Must aqui
RNF05 Documentação versionada Todos os artefatos (Rich Pictures, storyboards, gravações, vídeo demo, página HTML) devem ser versionados e publicados no GitHub Pages com histórico por contribuidor. Ambiental Must aqui
RNF06 Artefatos autorais Os artefatos visuais devem ser claramente feitos por humanos; conteúdo gerado por IA será penalizado conforme critério da professora. Ético Must aqui
RNF07 Exportação de sprites Os sprites e animações criados no Piskel devem ser exportados em formatos compatíveis com Godot (PNG por frame ou GIF). Produto Must aqui
RNF08 Validação com usuários reais O vídeo demo deve ser apresentado a ao menos dois usuários externos com experiência no gênero para coleta de feedback antes da entrega. Organizacional Should aqui
RNF09 Garantir a integridade dos dados no GitPages. Todo o histórico de versões e documentação deve ser mantido de forma íntegra no repositório do grupo. Ambiental Must aqui
RNF10 Tamanho dos blocos Cada bloco do cenário deve ter um tamanho T, em pixels. Espaço Must aqui
RNF11 Tamanho do jogador O jogador deve ter tamanho equivalente a 2T pixels. Espaço Must aqui
RNF12 Tamanho das ferramentas Ferramentas devem ter tamanho aproximado de 1,5T pixels. Espaço Must aqui
RNF13 tamanho do mundo O mundo deve ser pelo menos 1000x maior que o jogador Espaço Must aqui

Legenda: Must = obrigatório | Should = importante | Could = desejável | Wont = fora do escopo atual

Bibliografia

SOMMERVILLE, Ian. Engenharia de Software. 9. ed. São Paulo: Pearson Prentice Hall, 2011. Acesso em: 6 abr. 2026.

historico de versão

Versão Data Descrição Autor Revisor
1.0 12/04/2025 Criação do documento Heyttor Augusto
1.1 03/04/2026 Padronização e edição dos Requisitos seguindo FURPS+ Moscow Yasmin Abdon
1.2 03/04/2026 Revisão geral, acrescimo de requisitos e ajustes Carlos Henrique e João Pedro
1.3 04/04/2025 Adição de rastreabilidade e mudança do local do arquico Heyttor augusto Yasmin Abdon
1.4 04/04/2025 Mudança de local de arquivo (com correções da rastreabilidade para não gerar conflito) Yasmin Abdon
1.5 06/04/2025 Adição de referência bibliográfica e categorização de requisitos não funcionais (tipo) Yasmin Abdon