Requisitos de Software¶
Requisitos Funcionais¶
| ID | Nome do Requisito | Descrição do requisito |
|---|---|---|
| RF01 | Acessar conteúdo público | O sistema deve permitir que visitantes anônimos acessem a landing page sem necessidade de autenticação, para fins de divulgação e atração de clientes. |
| RF02 | Acessar links para redes sociais da escola | Fornecer links diretos e acessíveis para as redes sociais da escola e da instrutora. |
| RF03 | Consultar horários e planos disponíveis | Permitir à Aluna e Visitante consultar a grade completa de horários e os planos de aula disponíveis. |
| RF04 | Disponibilizar espaço para tirar dúvidas sobre a modalidade | Disponibilizar um canal ou seção para tirar dúvidas frequentes sobre a modalidade, logística e funcionamento da escola (FAQ). |
| RF05 | Cadastrar novo usuário | O usuário deve conseguir se cadastrar se for um usuário novo, em um campo onde informa dados como nome, e-mail e senha. |
| RF06 | Realizar login | O usuário deve conseguir realizar o login se cadastrado, utilizando e-mail e senha. |
| RF07 | Realizar logout | O usuário deverá conseguir realizar o logout, encerrando a sessão e redirecionando para a landing page. |
| RF08 | Comprar pacotes de aulas com pagamentos online por meio do Mercado Pago | O usuário deve conseguir comprar pacotes de aulas, exibindo opções disponíveis (ex.: pacote básico de 2 aulas semanais). |
| RF09 | Pagar por uma aula experimental com pagamentos online por meio do Mercado Pago | O usuário deve conseguir pagar por uma aula experimental. |
| RF10 | Agendar aulas | Permitir à Aluna agendar e cancelar aulas com base na disponibilidade do cronograma e no nível da turma. |
| RF11 | Exibir pacotes de aulas disponíveis conforme plano definido | Exibir apenas os pacotes compatíveis com o plano atribuído à aluna após a avaliação. |
| RF12 | Consultar cronograma de aulas agendadas | Permitir à Aluna consultar o cronograma individual de todas as aulas agendadas (histórico e futuras). |
| RF13 | Confirmar ausência da aula antecipadamente (Aluna) | A aluna deve conseguir confirmar ausência em uma aula agendada diretamente no painel do usuário (dashboard), com a opção disponível a qualquer momento antes do prazo de 12 horas antes do horário da aula. A confirmação deve atualizar o status da aluna de "Confirmado" para "Não confirmado". |
| RF14 | Gerar link de confirmação de ausência | A professora deve conseguir criar e compartilhar um link único para uma página dedicada de confirmação de ausência para uma aula específica, onde a aluna pode confirmar ausência até 12 horas antes do horário (conforme RF13 existente). A página deve incluir um countdown, botão de confirmação, texto sobre regulamento e aviso de login obrigatório se a aluna não estiver autenticada. |
| RF15 | Acessar painel administrativo | Permitir à Professora/Administradora acessar e gerenciar o painel administrativo para controle do negócio. |
| RF16 | Editar status de presença (Professora) | A professora deve conseguir editar manualmente o status de presença de qualquer aluna em uma aula específica, com opções de status: "Confirmado", "Não confirmado", "Ausente" ou "Presente". Essa edição deve ser acessível via painel administrativo da professora. |
| RF17 | Registrar presença após aula | Ao final de cada aula, a professora deve conseguir acessar uma seção dedicada à aula no site, exibindo uma lista de alunas agendadas com checkboxes de presença. Por padrão, todos os checkboxes devem estar ativados (indicando "Presente"), e a professora pode desmarcar os das alunas ausentes, atualizando o status para "Ausente". |
| RF18 | Gerenciar pacotes de aulas | Administradores devem conseguir gerenciar pacotes de aulas (criar, editar, deletar), incluindo preços e descrições. |
| RF19 | Gerenciar calendário de aulas | Administradores devem conseguir gerenciar o calendário de aulas (adicionar, editar, cancelar aulas). |
| RF20 | Agendar aula experimental | Permitir que novas alunas agendem uma aula experimental. |
| RF21 | Registrar resultado da avaliação | Permitir que a professora registre o resultado da avaliação da aula experimental da nova aluna. |
| RF22 | Definir plano da aluna | Permitir que a professora defina o plano (A ou B) da nova aluna com base no resultado da avaliação. |
Requisitos Não Funcionais¶
| ID | Nome do Requisito | Descrição do requisito | Tipo de Requisito |
|---|---|---|---|
| RNF01 | Implementar criptografia para a privacidade dos dados do usuário | Implementar criptografia de transporte (comunicação cliente-servidor) TLS 1.2 (ou superior) e, para as senhas de usuários, utilizar o algoritmo de hashing bcrypt com um fator de custo mínimo de 12. | Security |
| RNF02 | Assegurar conformidade com a Lei Geral de Proteção de Dados (LGPD) | O sistema deve garantir a conformidade com as exigências da LGPD, especialmente nos seguintes pontos: Consentimento (Art. 7º, I) no cadastro; Finalidade (Art. 6º, I); Segurança dos Dados (Art. 46); e Direito de Acesso e Exclusão (Art. 18, II e IV). | Externo: legal |
| RNF03 | Assegurar responsividade do site em diferentes dispositivos | O design e a interface do usuário devem assegurar a responsividade para dispositivos móveis (360px a 767px, smartphones de 5 a 6.7 polegadas) e desktop (larguras a partir de 1024px). | Usability |
| RNF04 | Manter o sistema disponível 24/7 (com exceção de manutenções programadas) | Disponibilidade mínima: 99,8% do tempo. Manutenção programada: período semestral de até 4 horas, preferencialmente fora do horário comercial (madrugada de domingo), para atualizações críticas de infraestrutura e informações ou estáticas da escola/planos. | Reliability |
| RNF05 | Garantir compatibilidade com os principais navegadores modernos | O site deve funcionar plenamente nas duas versões mais recentes dos principais navegadores modernos (Chrome, Firefox, Edge e Safari). | Reliability |
| RNF06 | Garantir interface intuitiva e fácil de navegar | O sistema deve garantir uma interface intuitiva e fácil de navegar, utilizando como cor primária o roxo (#BC3FDE) e seguindo a paleta de cores “purple” do site shadcn, baseando-se na identidade visual da escola. Fonte padrão: Montserrat, tamanho mínimo 14. | Usability |
| RNF07 | Garantir carregamento rápido e navegação fluida do frontend | Garantir tempo de carregamento inicial < 3 segundos em conexões 3G e tempo de resposta do servidor (TTFB) < 400ms para 90% das requisições. | Performance |
| RNF08 | Documentar padrões de desenvolvimento internos | A equipe deve documentar e seguir um padrão interno para as práticas de desenvolvimento (código, testes, infraestrutura). | Organizacional: Desenvolvimento |
| RNF09 | Otimizar Motores de Busca (SEO) | O sistema deve ser otimizado para motores de busca SEO, implementando SEO On-Page (meta tags, cabeçalhos, atributos alt em imagens) e SEO Off-Page (Google Business Profile), com foco em palavras-chave relacionadas à escola e modalidade. | Performance |
| RNF10 | Implementar medidas de segurança contra vulnerabilidades | Implementar validação e sanitização de todas as entradas no backend usando parametrização de consultas (prevenir SQL Injection) e configurar mitigação de DNS Tunneling via TLS; aplicar políticas de segurança como CORS para filtrar domínios externos. | Security |
| RNF11 | Exibir menu de navegação | Fornecer menu de navegação principal com links para todas as páginas: Landing Page, Sobre, Pole Dance, Turmas e Horários, Valores, Regulamento, FAQ, Login/Cadastro. | Usability |
| RNF12 | Exibir landing page | Exibir landing page inicial com informações sobre a escola de pole dance, incluindo descrição dos serviços, depoimentos de alunos e chamadas para ação (CTAs) para cadastro ou login. | Usability |
Valor de Negócio x Avaliação Técnica¶
Valor de Negócio¶
Quão importante a funcionalidade é para a cliente e para o faturamento (com base no MoSCoW: Must/Should/Could).
| Pontuação | Descrição do Valor para a Escola | Categoria MoSCoW |
|---|---|---|
| Alto (3) | Essencial para o faturamento e para resolver a dor crítica. | Must-Have |
| Médio (2) | Importante para a satisfação, mas o sistema funciona sem ele. | Should-Have |
| Baixo (1) | Adicional, apenas melhora a experiência ou é um diferencial futuro. | Could-Have |
Avaliação Técnica (Esforço)¶
Quanto tempo e a complexidade que o time de desenvolvimento estima para construir a funcionalidade.
| Pontuação | Descrição do Esforço para o Desenvolvimento |
|---|---|
| Alto (3) | Envolve integrações complexas, novas tecnologias ou alta incerteza (risco). |
| Médio (2) | Complexidade moderada, exige front e back, mas com tecnologia dominada. |
| Baixo (1) | Implementação simples, é estático ou utiliza componentes prontos. |
Tabela: Valor de Negócio x Avaliação Técnica x MoSCoW¶
| Requisito | Valor (1-3) | Esforço (1-3) | MoSCoW | Está no MVP? |
|---|---|---|---|---|
| RF01 - Acessar conteúdo público | 3 | 1 | MUST | ☑️ |
| RF02 - Acessar links para redes sociais da escola | 3 | 1 | MUST | ⬜ |
| RF03 - Consultar horários e planos disponíveis | 3 | 1 | MUST | ☑️ |
| RF04 - Disponibilizar espaço para tirar dúvidas sobre a modalidade | 2 | 1 | SHOULD | ⬜ |
| RF05 - Cadastrar novo usuário | 3 | 2 | MUST | ☑️ |
| RF06 - Realizar login | 3 | 2 | MUST | ☑️ |
| RF07 - Realizar logout | 3 | 2 | MUST | ⬜ |
| RF08 - Comprar pacotes de aulas com pagamentos online por meio do Mercado Pago | 3 | 2 | MUST | ☑️ |
| RF09 - Pagar por uma aula experimental com pagamentos online por meio do Mercado Pago | 3 | 2 | MUST | ☑️ |
| RF10 - Agendar aulas | 3 | 3 | MUST | ☑️ |
| RF11 - Agendar aulas específicas | 3 | 2 | MUST | ⬜ |
| RF12 - Consultar cronograma de aulas agendadas | 3 | 2 | MUST | ⬜ |
| RF13 - Confirmar ausência da aula antecipadamente (Aluna) | 1 | 3 | SHOULD | ⬜ |
| RF14 - Gerar link de confirmação de ausência | 1 | 2 | COULD | ⬜ |
| RF15 - Acessar painel administrativo | 3 | 2 | MUST | ☑️ |
| RF16 - Editar status de presença (Professora) | 1 | 2 | MUST | ☑️ |
| RF17 - Registrar presença das alunas pós aula | 3 | 2 | MUST | ☑️ |
| RF18 - Gerenciar pacotes de aulas | 2 | 2 | MUST | ☑️ |
| RF19 - Gerenciar calendário de aulas | 3 | 1 | MUST | ☑️ |
| RF20 - Agendar aula experimental | 3 | 2 | MUST | ☑️ |
| RF21 - Registrar resultado da avaliação | 2 | 2 | MUST | ☑️ |
| RF22 - Definir plano da aluna | 2 | 2 | MUST | ☑️ |
| RNF01 - Implementar criptografia para a privacidade dos dados do usuário | 3 | 2 | SHOULD | ⬜ |
| RNF02 - Assegurar conformidade com a Lei Geral de Proteção de Dados (LGPD) | 3 | 3 | MUST | ⬜ |
| RNF03 - Assegurar responsividade do site em diferentes dispositivos | 3 | 2 | MUST | ⬜ |
| RNF04 - Manter o sistema disponível 24/7 (com exceção de manutenções programadas) | 3 | 2 | MUST | ⬜ |
| RNF05 - Garantir compatibilidade com os principais navegadores modernos (Chrome, Firefox, Edge, Safari) | 2 | 1 | MUST | ⬜ |
| RNF06 - Garantir interface intuitiva e fácil de navegar | 3 | 1 | MUST | ☑️ |
| RNF07 - Garantir carregamento rápido e navegação fluida do frontend | 2 | 2 | MUST | ⬜ |
| RNF08 - Documentar padrões de desenvolvimento internos | 1 | 1 | SHOULD | ⬜ |
| RNF09 - Otimizar Motores de Busca (SEO) através de meta tags e palavras chaves (SEO On-Page) e SEO Off-Page | 3 | 2 | MUST | ⬜ |
| RNF10 - Implementar medidas de segurança contra abuso de vulnerabilidades como SQL Injection ou DNS Tunneling | 3 | 2 | SHOULD | ⬜ |
| RNF11 - Exibir menu de navegação | 3 | 1 | MUST | ⬜ |
| RNF12 - Exibir landing page | 3 | 1 | MUST | ☑️ |
O lançamento do MVP será seguido por uma fase de testes e coleta de dados, visando a validação da hipótese de valor.