Especificação de Requisitos
Cruzeiro e Remo em Números - Versão 1.3 17/06/2026
Mantenedor(es): Antonio G. Castro. João Pedro Santos de Brito.
Sumário
1. Prefácio
Esse documento é destinado aos interessados diretos e indiretos do projeto Cruzeiro e Remo em Números. Stakeholders, professores, desenvolvedores, clientes, entre outros.
2. Histórico de versões
| Versão | Data | Justificativa | Autor |
|---|---|---|---|
| 1.0 | 29/01/2026 | Adição da estrutura básica do documento | Antonio G. Castro |
| 1.1 | 02/02/2026 | Edição da estrutura e adição de requisitos US-01, US-02 e US-03 | Antonio G. Castro |
| 1.2 | 05/02/2026 | Edição da estrutura, adição dos requisitos não funcionais, manutenção do glossário, Objetivos do negócio, visão do produto, principais funcionalidades e limitações | Antonio G. Castro |
| 1.3 | 17/06/2026 | Edição dos requisitos de listagem e filtragem, revisão para conversão para Docusaurus | Antonio G. Castro |
3. Introdução
3.1 Background e oportunidades do negócio
…
Logo, ao unir o presente momento dos clubes citados (Cruzeiro Esporte Clube e Clube do Remo), a popularidade do futebol como esporte e entretenimento no Brasil e a ausência de fontes completas, fica evidente a oportunidade de lançar ao público plataformas que contenham as estatísticas históricas de ambos os clubes. Com o intuito de trazer ao público e aos torcedores informações e análises profundas com ampla base histórica.
3.2 Objetivos do negócio
O sistema visa simplificar o processo de acompanhamento histórico dos clubes esportivos Cruzeiro Esporte Clube e Clube do Remo, atuando como fonte de pesquisa entre torcedores, amantes do esporte e demais interessados no retrospecto das equipes. O objetivo é proporcionar uma plataforma de fácil uso que liga interessados a informações de forma transparente e confiável.
3.3 Visão do produto
A ideia do sistema surgiu diante da ausência de fontes completas e dedicadas de ambos os clubes, inspirados no sistema Meu Time na Rede (fonte histórica do Criciúma Esporte Clube). O grande diferencial do sistema é a fonte de seus dados, que mesclam dados disponíveis no site Futebol80 com outras fontes de informação.
No caso do Clube do Remo, os dados foram alimentados pelo Professor Doutor, e torcedor do Clube do Remo, Cássio Pinho Reis em buscas textuais em súmulas e bibliotecas locais do Pará. Como principal fonte de dados para o histórico do Cruzeiro Esporte Clube, iremos utilizar o site CruzeiroPedia, que serviu como base para o futebol80.
4. Glossário
| Termo | Descrição |
|---|---|
| Mando de campo | Direito de uma equipe jogar em seu próprio estádio, em sua cidade, como anfitriã em uma partida. |
| MVP | Produto mínimo viável, versão mais básica de um produto, com apenas funcionalidades essenciais e objetivo de ser lançado rapidamente. |
5. Definição de requisitos
5.1 Requisitos funcionais
ID: US-01 - Visualizar partidas
História de usuário:
COMO usuário QUERO visualizar, por meio de uma tabela, todos os jogos da história do clube PARA acompanhar resultados de temporadas anteriores
Regras de negócio:
- A tabela deve possuir as seguintes colunas: clube (Cruzeiro ou Remo), adversário, data da partida, competição, mando de campo e placar.
ID: US-02 - Filtrar partidas
História de usuário:
COMO usuário QUERO filtrar as partidas PARA selecionar precisamente as informações que quero ver
Regras de negócio:
- A filtragem deve ser feita pelos seguintes atributos: mando de campo, estado do adversário, adversário, competição e intervalo de tempo;
- A filtragem ocorrerá por um menu, acima do cabeçalho da tabela;
- O menu e o ícone devem ser fiéis ao protótipo.
ID: US-03 - Ordenar partidas
História de usuário:
COMO usuário QUERO ordenar as partidas PARA facilitar a visualização da tabela
Regras de negócio:
- A ordenação deve ser feita pelo atributo data.
ID: US-O4 - Card de títulos
História de usuário
COMO Usuário do App, QUERO visualizar um card fixo com todos os títulos da história do clube, PARA conhecer rapidamente o histórico de conquistas do time.
Regras de negócio
- O card deve ser o primeiro elemento da tela
- O card deve ser responsivo, adequando-se ao tamanho da tela
- A fonte dos dados será o site oficial do Remo
- Todos os títulos já conquistados na história devem estar presentes no card
ID: US-05 - Card de próximo jogo
História de usuário
COMO usuário do app, QUERO visualizar as informações do próximo jogo do clube (data, horário, adversário e local), PARA me manter informado sem precisar buscar essas informações em outras fontes.
Regras de negócio
- Exibir a data e o horário da próxima partida.
- Exibir o adversário da partida.
- Exibir o local (estádio ou cidade) da partida.
- Exibir apenas a próxima partida agendada.
- Caso não exista uma próxima partida cadastrada, informar isso ao usuário.
ID: US-06 - Card de curiosidade
História de usuário
COMO usuário do app, QUERO visualizar diariamente uma curiosidade ou métrica destacada (como invencibilidade, jejum ou tabu), PARA ter um conteúdo novo e relevante a cada acesso.
Regras de negócio
- Exibir apenas uma curiosidade ou métrica em destaque por dia.
- A informação exibida deve ser atualizada diariamente.
- A curiosidade deve possuir um texto claro e de fácil compreensão.
- Caso não exista uma curiosidade disponível para o dia, exibir uma mensagem informativa ao usuário.
5.2 Requisitos não funcionais
5.2.1 Confiabilidade
- RNF-1. O sistema deve ser capaz de lidar com grande volume de usuários e requisições;
- RNF-2. O sistema deve implementar medidas de segurança para proteger os dados.
5.2.2 Eficiência
- RNF-4. O sistema deve fornecer uma resposta rápida às solicitações dos usuários, garantindo uma experiência de uso fluída;
- RNF-5. O sistema deve fornecer recursos de filtragem e navegação eficientes, permitindo que o usuário localize rapidamente dados específicos.
5.2.3 Disponibilidade
- RNF-6. O sistema deve estar disponível para o usuário a maior parte do tempo, com o mínimo tempo de inatividade planejado ou não.
5.2.4 Portabilidade
- RNF-7. O sistema deve ser capaz de ser utilizado em diferentes navegadores web (Google Chrome, Firefox, Opera, Microsoft Edge, Brave, Safari) com alteração mínima em sua performance;
- RNF-8. O sistema deve ser responsivo, adequando-se a dispositivos mobile e web.
5.3.5 Limitações
- RNF-9. O sistema não contará com autenticação;
- RNF-10. O sistema não irá diferenciar seus usuários através de classes de usuários;
- RNF-11. A manutenção do banco de dados será feita pelos mantenedores do projeto, através de linhas de comando.