Requisitos — app-nuree¶
Formato, metadados e esquema de IDs em convenção de escrita.
E1 — Login, papéis e acesso aos dados por empresa e programa¶
Alicerce multi-tenant: quem é quem e o que cada um enxerga. É a base de que todos os outros épicos dependem.
| ID | Requisito | Ator | Prioridade | Depende de | Fonte | Verificação |
|---|---|---|---|---|---|---|
| RF-E1.1 | O sistema deve representar Produtos a partir de um catálogo fixo (Gestão, Pessoas, Lab, Pulse). | Sistema | Alta | — | Reunião de discovery - produtos nuree 29/07 | Cada produto existe e é selecionável ao criar um programa. |
| RF-E1.2 | O sistema deve permitir criar Programas como instância de um Produto para uma Empresa, com período opcional. | Admin | Alta | RF-E1.1 | Reunião de discovery - produtos nuree 29/07 | Criar um programa vinculado a produto+empresa e recuperá-lo. |
| RF-E1.2a | O sistema deve permitir que uma mesma Empresa tenha mais de um contrato simultâneo — cada contrato é um Programa — com dados isolados entre eles. | Sistema | Alta | RF-E1.2 | Reunião de discovery - produtos nuree 29/07 | Uma empresa com dois programas não vaza dados de um para o outro. |
| RF-E1.3 | O sistema deve vincular usuários a um Programa (Participação), com o pacote contratado. | Admin | Alta | RF-E1.2 | Reunião de discovery - produtos nuree 29/07 | Matricular um cliente num programa com o seu pacote. |
| RF-E1.4 | O sistema deve autenticar usuários por e-mail e código de uso único (OTP) enviado por e-mail, e manter a sessão. | Todos | Alta | — | Decisão de projeto | Código válido concede sessão; inválido ou expirado é recusado. |
| RF-E1.4a | O sistema deve classificar cada usuário por um papel de plataforma (Admin ou Cliente), que determina seu nível de acesso. | Sistema | Alta | RF-E1.4 | Inferência | Usuário Admin e usuário Cliente têm níveis de acesso distintos. |
| RF-E1.5 | O sistema deve emitir códigos OTP de uso único e expiração curta, invalidando-os após o uso ou a expiração; o mesmo fluxo serve ao primeiro acesso. | Todos | Média | RF-E1.4 | Decisão de projeto | Código expira e não se reusa; reenvio gera um novo. |
| RF-E1.6 | O sistema deve restringir todo acesso a dados de um programa ao escopo (empresa/programa) do usuário. | Cliente | Alta | RF-E1.4a | AGENTS.md | Usuário de uma empresa não lê dados de outra. |
| RF-E1.7 | Se um usuário solicitar dados fora do seu escopo, então o sistema deve negar o acesso, exceto para o papel Admin. | Cliente | Alta | RF-E1.6 | AGENTS.md | Requisição fora de escopo retorna negação; Admin acessa. |
| RF-E1.8 | O sistema deve permitir a autenticação via conta Google (OAuth), de forma complementar ao login por e-mail e código. | Todos | Média | RF-E1.4 | Decisão de projeto | Entrar com Google e, na mesma conta, entrar por e-mail e código. |
| RF-E1.9 | Se um usuário autentica com Google e já existe conta com aquele e-mail, então o sistema deve vincular as identidades em vez de criar conta duplicada. | Todos | Média | RF-E1.8 | Decisão de projeto | Login Google com e-mail já cadastrado reutiliza a conta existente. |
| RF-E1.10 | O sistema deve permitir ao usuário encerrar a sessão (logout). | Todos | Média | RF-E1.4 | Inferência | Logout encerra a sessão e exige novo login. |
| RF-E1.11 | O sistema deve expirar a sessão após período de inatividade, exigindo novo login. | Sistema | Média | RF-E1.4 | Inferência | Após inatividade, o acesso pede login de novo. |
| RF-E1.12 | O sistema deve coletar telefone (obrigatório) no cadastro de usuário — pelo admin ou por link — e confirmar o e-mail antes de liberar o primeiro acesso. | Todos | Média | RF-E1.4, RF-E2.2 | Decisão de projeto | Sem telefone o cadastro não conclui; e-mail não confirmado não acessa. |
| RF-E1.13 | O sistema deverá futuramente exigir a confirmação do telefone (celular) do usuário, além da de e-mail. | Todos | Baixa | RF-E1.12 | Decisão de projeto | (futuro) Confirmar o celular além do e-mail. |
E2 — Administrar empresas, usuários e programas¶
Painel onde o admin opera e configura os motores sem depender do dev.
| ID | Requisito | Ator | Prioridade | Depende de | Fonte | Verificação |
|---|---|---|---|---|---|---|
| RF-E2.1 | O sistema deve permitir criar, editar e desativar Empresas. | Admin | Alta | RF-E1.4a | Reunião de discovery - produtos nuree 29/07 | CRUD completo de empresa (exclusão é soft — RNF-9). |
| RF-E2.2 | O sistema deve permitir criar, editar e desativar usuários, incluindo papel e reenvio de acesso. | Admin | Alta | RF-E1.4a | Reunião de discovery - produtos nuree 29/07 | Criar usuário, alterar papel, reenviar acesso, desativar. |
| RF-E2.3 | O sistema deve permitir criar Programas e matricular clientes. | Admin | Alta | RF-E1.2, RF-E1.3 | Reunião de discovery - produtos nuree 29/07 | Criar programa e matricular pessoas gerando participações. |
| RF-E2.4 | O sistema deve oferecer um ponto único de acesso aos construtores (formulários, jornadas, trilhas, selos, réguas, templates de ciclo) e à biblioteca de mídia. | Admin | Alta | RF-E1.4a | Reunião de discovery - produtos nuree 29/07 | A partir do hub, alcançar cada construtor. |
| RF-E2.5 | Onde o admin possui múltiplas empresas/programas, o sistema deve permitir alternar o contexto ativo. | Admin | Alta | RF-E1.2a | Reunião de discovery - produtos nuree 29/07 | Trocar o contexto muda o quadro exibido. |
| RF-E2.6 | O sistema deve oferecer painéis de acompanhamento por Programa e por Pessoa. | Admin | Média | RF-E1.3 | Reunião de discovery - produtos nuree 29/07 | Ver as tarefas/sessões de uma pessoa agrupadas. |
| RF-E2.7 | O sistema deve permitir clonar ou reaplicar um template (formulário, jornada, trilha, selo) a outro programa sem recriá-lo. | Admin | Média | RF-E2.4 | Reunião de discovery - produtos nuree 29/07 | Aplicar um mesmo formulário a dois programas. |
| RF-E2.8 | Quando o admin cria um usuário, o sistema deve enviar um e-mail de convite com o acesso inicial. | Sistema | Média | RF-E2.2 | Decisão de projeto | Criar usuário dispara e-mail de convite com acesso. |
| RF-E2.9 | O sistema deve permitir ao admin gerar um link de cadastro (aberto) vinculado a uma Empresa. | Admin | Média | RF-E2.1 | Decisão de projeto | Gerar o link de cadastro de uma empresa e recuperá-lo. |
| RF-E2.10 | Quando alguém acessa um link de cadastro, o sistema deve permitir o autocadastro (nome, e-mail, telefone) já associado à Empresa do link, sem permitir editar esse vínculo. | Todos | Média | RF-E2.9, RF-E1.3 | Decisão de projeto | O cadastro pelo link cria o usuário na empresa do link; a empresa não é editável. |
| RF-E2.11 | Após o primeiro acesso, o sistema deve conduzir o usuário ao preenchimento do carômetro (perfil), passo a passo. | Cliente | Baixa | RF-E2.10 | Decisão de projeto | O primeiro login abre o preenchimento do carômetro em etapas. |
E3 — Organizar e acompanhar tarefas em ciclos¶
Base de acompanhamento (já em produção); passa a pertencer ao Programa. CRUD completo de tarefas e ciclos.
| ID | Requisito | Ator | Prioridade | Depende de | Fonte | Verificação |
|---|---|---|---|---|---|---|
| RF-E3.1 | Quando um usuário cria uma tarefa, o sistema deve exigir o título; o responsável assume o criador e o status assume "a fazer" por padrão. | Cliente | Alta | RF-E1.6 | Existente | Criar tarefa só com título; responsável = criador, status = a fazer. |
| RF-E3.2 | O sistema deve permitir editar título, responsável, status, descrição, ciclo e prazo de uma tarefa. | Cliente | Alta | RF-E3.1 | Existente | Alterar cada campo e persistir. |
| RF-E3.3 | O sistema deve permitir excluir uma tarefa, removendo também suas subtarefas. | Cliente | Alta | RF-E3.1 | Inferência | Excluir tarefa a remove com suas subtarefas. |
| RF-E3.4 | O sistema deve permitir mover uma tarefa entre os estados a fazer, fazendo e feita. | Cliente | Alta | RF-E3.1 | Existente | Mover a tarefa pelos três estados. |
| RF-E3.5 | O sistema deve permitir adicionar, marcar como feita e remover subtarefas de uma tarefa. | Cliente | Média | RF-E3.1 | Existente | Adicionar subtarefa, marcá-la e removê-la. |
| RF-E3.6 | Quando o admin cria um ciclo, o sistema deve exigir nome, data de início e data de fim. | Admin | Alta | RF-E1.4a | Existente | Criar ciclo exige os três campos; só admin cria. |
| RF-E3.7 | O sistema deve permitir ao admin editar nome, data de início e data de fim de um ciclo. | Admin | Alta | RF-E3.6 | Inferência | Admin altera os campos do ciclo; cliente não. |
| RF-E3.8 | O sistema deve permitir ao admin excluir um ciclo, excluindo também suas tarefas e as subtarefas delas. | Admin | Média | RF-E3.6 | Decisão de projeto | Excluir um ciclo remove também suas tarefas e subtarefas; só admin. |
| RF-E3.9 | O sistema deve permitir ao admin encerrar um ciclo; as tarefas não concluídas passam automaticamente para o próximo ciclo (ou à sementeira, se não houver). | Admin | Alta | RF-E3.6 | Decisão de projeto | Encerrar move as tarefas abertas para o próximo ciclo. |
| RF-E3.10 | O sistema deve organizar as tarefas em ciclos e, quando sem ciclo, na sementeira. | Cliente | Alta | RF-E3.1, RF-E3.6 | Existente | Tarefa sem ciclo aparece na sementeira. |
| RF-E3.11 | O sistema deve exibir as tarefas em visões de lista, kanban e calendário. | Todos | Média | RF-E3.1 | Existente | Alternar entre as três visões. |
| RF-E3.12 | O sistema deve permitir definir templates de ciclo (ex.: Florescimento) e instanciá-los num programa, gerando ciclo e tarefas. | Admin | Alta | RF-E3.6, RF-E2.4 | Reunião de discovery - produtos nuree 29/07 | Instanciar o template cria o ciclo com as tarefas do checklist. |
E4 — Criar formulários e coletar respostas¶
Motor único de formulários, reusado por Mergulho, tarefas de casa, assessment/PDI e diagnóstico.
| ID | Requisito | Ator | Prioridade | Depende de | Fonte | Verificação |
|---|---|---|---|---|---|---|
| RF-E4.1 | O sistema deve permitir criar, editar e excluir formulários com campos de tipos variados (texto curto, texto longo, escolha única, escolha múltipla, escala, número, data e upload). | Admin | Alta | RF-E2.4 | Reunião de discovery - produtos nuree 29/07 | Criar um formulário com um campo de cada tipo e persistir. |
| RF-E4.2 | O sistema deve permitir configurar cada campo quanto a rótulo, obrigatoriedade, opções e ordem. | Admin | Alta | RF-E4.1 | Inferência | Reordenar campos e marcar obrigatoriedade. |
| RF-E4.3 | O sistema deve permitir atribuir um formulário a um contexto (programa, etapa de jornada ou participação), com prazo. | Admin | Alta | RF-E4.1, RF-E1.2 | Inferência | Atribuir o mesmo formulário a dois contextos distintos. |
| RF-E4.4 | O sistema deve permitir responder um formulário atribuído, salvando rascunho antes do envio. | Cliente | Alta | RF-E4.3, RF-E1.3 | Reunião de discovery - produtos nuree 29/07 | Salvar rascunho, sair, retomar e enviar. |
| RF-E4.5 | Quando um cliente envia uma resposta, o sistema deve registrá-la e emitir um evento para os módulos interessados. | Sistema | Alta | RF-E4.4 | Inferência | Envio dispara o evento de resposta enviada. |
| RF-E4.6 | Onde um formulário for do tipo avaliado (quiz), o sistema deve registrar gabarito e pontuação e, opcionalmente, um tempo-limite. | Admin/Sistema | Média | RF-E4.1 | Reunião de discovery - produtos nuree 29/07 | Responder um quiz produz pontuação conforme o gabarito. |
E5 — Agendar e registrar sessões de mentoria¶
Auto-agendamento com regras + registro do que foi combinado. A gestão das sessões e da disponibilidade é do admin (o mentor).
| ID | Requisito | Ator | Prioridade | Depende de | Fonte | Verificação |
|---|---|---|---|---|---|---|
| RF-E5.1 | O sistema deve permitir ao admin publicar a disponibilidade de mentoria em slots finitos. | Admin | Alta | RF-E1.2 | Reunião de discovery - produtos nuree 29/07 | Publicar slots que ficam visíveis para agendamento. |
| RF-E5.2 | O sistema deve permitir ao cliente agendar uma sessão num slot disponível, respeitando o limite do pacote. | Cliente | Alta | RF-E5.1, RF-E1.3 | Reunião de discovery - produtos nuree 29/07 | Agendar até o limite; além dele é bloqueado. |
| RF-E5.3 | O sistema não deve permitir a remarcação de sessões. | Sistema | Alta | RF-E5.2 | Reunião de discovery - produtos nuree 29/07 | Não há ação de remarcar uma sessão agendada. |
| RF-E5.4 | O sistema deve permitir ao cliente transferir uma sessão a um colega da mesma empresa, notificando os envolvidos. | Cliente | Média | RF-E5.2 | Reunião de discovery - produtos nuree 29/07 | Transferir a sessão para colega da mesma empresa; terceiros não. |
| RF-E5.5 | O sistema deve exibir ao cliente a linha do tempo das suas sessões. | Cliente | Média | RF-E5.2 | Reunião de discovery - produtos nuree 29/07 | Ver 1ª, 2ª, 3ª sessão com datas e estado. |
| RF-E5.6 | Quando ocorre uma sessão, o sistema deve permitir ao admin confirmar a realização e registrar o combinado (ex.: fez mais / fez menos). | Admin | Alta | RF-E5.2 | Reunião de discovery - produtos nuree 29/07 | Confirmar a sessão e gravar o combinado. |
| RF-E5.7 | Quando uma sessão é agendada, o sistema deve programar as mensagens de lembrete correspondentes. | Sistema | Média | RF-E5.2, RF-E9.1 | Reunião de discovery - produtos nuree 29/07 | Agendamento cria disparos de lembrete (ver E9). |
| RF-E5.8 | O sistema deve permitir ao admin conectar a conta Google (Calendar) do mentor por OAuth. | Admin | Média | RF-E1.4a | Decisão de projeto | Conectar o Google e o vínculo persiste. |
| RF-E5.9 | Onde a agenda Google estiver conectada e uma sessão for agendada, o sistema deve criar o evento correspondente no Google Calendar do mentor e do cliente, com convite. | Sistema | Média | RF-E5.2, RF-E5.8 | Decisão de projeto | Com Google conectado, agendar cria o evento e envia convite. |
| RF-E5.10 | Enquanto a agenda Google estiver conectada, o sistema deve considerar seus horários ocupados para bloquear slots em conflito. | Sistema | Média | RF-E5.8, RF-E5.1 | Decisão de projeto | Horário ocupado no Google não aparece como slot disponível. |
| RF-E5.11 | O sistema deve permitir ao admin cancelar ou remover sessões e criar, editar ou remover a disponibilidade. | Admin | Média | RF-E5.1 | Decisão de projeto | Admin cancela sessão e gerencia os slots. |
| RF-E5.12 | Se um cliente tentar cancelar, editar ou remover uma sessão ou a disponibilidade, então o sistema deve negar. | Cliente | Média | RF-E5.11 | Decisão de projeto | Cliente não cancela/edita/remove sessão nem slot. |
| RF-E5.13 | O sistema deve permitir ao cliente responder um check-in (formulário) vinculado a uma sessão online, com estrutura própria distinta do check-in presencial de eventos. | Cliente | Média | RF-E5.2, RF-E4.3 | Reunião de exploração de arquitetura 02/08 | Responder um check-in atrelado a uma sessão agendada. |
E6 — Publicar conteúdo e trilhas de reforço¶
Biblioteca de reforço de aprendizagem, montada pelo admin.
| ID | Requisito | Ator | Prioridade | Depende de | Fonte | Verificação |
|---|---|---|---|---|---|---|
| RF-E6.1 | O sistema deve permitir criar, editar e excluir trilhas compostas por itens ordenados (pílula de texto, vídeo, leitura, quiz — via RF-E4.6). | Admin | Média | RF-E2.4, RF-E4.6 | Reunião de discovery - produtos nuree 29/07 | Montar uma trilha com um item de cada tipo. |
| RF-E6.2 | O sistema deve armazenar e servir a mídia dos itens de trilha. | Sistema | Média | RF-E6.1 | Reunião de discovery - produtos nuree 29/07 | Subir um vídeo e reproduzi-lo no item. |
| RF-E6.3 | O sistema deve permitir ao cliente consumir os itens e marcar o progresso. | Cliente | Média | RF-E6.1, RF-E1.3 | Reunião de discovery - produtos nuree 29/07 | Marcar item como concluído e ver o progresso. |
| RF-E6.4 | O sistema não deve bloquear conteúdo por não-conclusão (reforço, não vigilância). | Sistema | Média | RF-E6.3 | Reunião de discovery - produtos nuree 29/07 | Todos os itens acessíveis independentemente do progresso. |
E7 — Montar e exibir a jornada do participante¶
Espinha que amarra encontros, formulários, trilhas e selos numa linha do tempo. Também um construtor.
| ID | Requisito | Ator | Prioridade | Depende de | Fonte | Verificação |
|---|---|---|---|---|---|---|
| RF-E7.1 | O sistema deve permitir montar, editar e excluir jornadas com etapas ordenadas (marco, encontro, formatura), cada uma com data ou offset. | Admin | Média | RF-E2.4 | Reunião de discovery - produtos nuree 29/07 | Criar jornada com marco zero, encontros e formatura. |
| RF-E7.2 | O sistema deve permitir anexar a uma etapa um formulário, uma trilha e/ou um selo. | Admin | Média | RF-E7.1, RF-E4.1, RF-E6.1, RF-E8.1 | Reunião de discovery - produtos nuree 29/07 | Anexar os três a uma etapa. |
| RF-E7.3 | O sistema deve exibir ao cliente a sua jornada e o progresso nela. | Cliente | Média | RF-E7.1, RF-E1.3 | Reunião de discovery - produtos nuree 29/07 | Cliente vê a linha do tempo e onde está. |
| RF-E7.4 | Quando o cliente conclui uma etapa, o sistema deve registrar a conclusão e emitir um evento. | Sistema | Média | RF-E7.3 | Inferência | Concluir etapa dispara o evento de etapa concluída. |
E8 — Conceder selos por progresso (gamificação)¶
Selos por pilar/competência, silenciosos e editoriais.
| ID | Requisito | Ator | Prioridade | Depende de | Fonte | Verificação |
|---|---|---|---|---|---|---|
| RF-E8.1 | O sistema deve permitir definir, editar e excluir selos (por pilar ou competência) e seus critérios de concessão. | Admin | Média | RF-E2.4 | Reunião de discovery - produtos nuree 29/07 | Criar selo com critério vinculado a uma etapa/trilha. |
| RF-E8.2 | Quando um critério de selo é satisfeito, o sistema deve conceder o selo ao cliente. | Sistema | Média | RF-E8.1, RF-E7.4 | Reunião de discovery - produtos nuree 29/07 | Cumprir o critério concede o selo automaticamente. |
| RF-E8.3 | O sistema deve exibir os selos do cliente em estética silenciosa, sem ranking, streak ou confete. | Cliente | Média | RF-E8.2 | PRODUCT.md | Tela de selos sem elementos competitivos. |
E9 — Enviar mensagens automáticas por WhatsApp¶
Mensagens automáticas antes e depois de cada encontro.
| ID | Requisito | Ator | Prioridade | Depende de | Fonte | Verificação |
|---|---|---|---|---|---|---|
| RF-E9.1 | O sistema deve permitir criar, editar e excluir modelos de mensagem com gatilho, canal WhatsApp e variáveis. | Admin | Média | RF-E2.4 | Reunião de discovery - produtos nuree 29/07 | Criar modelo com variáveis e gatilho. |
| RF-E9.2 | Quando um gatilho ocorre (antes/depois de encontro, ou X horas antes de uma sessão), o sistema deve agendar o disparo. | Sistema | Média | RF-E9.1, RF-E7.1 | Reunião de discovery - produtos nuree 29/07 | Gatilho cria um disparo agendado para o momento certo. |
| RF-E9.3 | O sistema deve enviar as mensagens via WhatsApp e registrar o status (agendado, enviado, falhou), com novas tentativas em caso de falha. | Sistema | Média | RF-E9.2 | Decisão de projeto | Disparo enviado atualiza status; falha gera retry. |
E10 — Diagnosticar áreas da empresa e gerar planos de ação¶
Diagnóstico de maturidade de qualquer área da empresa (RH no Nuree Pessoas, gestão/OKR no Nuree Gestão, etc.) + planos de ação. Em grande parte, composição de E4 (formulário) + E3 (tarefas).
| ID | Requisito | Ator | Prioridade | Depende de | Fonte | Verificação |
|---|---|---|---|---|---|---|
| RF-E10.1 | O sistema deve permitir montar um diagnóstico organizando as perguntas por dimensão/área, respondidas numa escala de maturidade de 1 a 5. | Admin | Média | RF-E4.1 | Reunião de discovery - produtos nuree 29/07 | Montar diagnóstico com dimensões e perguntas em escala de 1 a 5. |
| RF-E10.2 | O sistema deve calcular a maturidade por dimensão e a geral a partir das respostas e exibir o resultado. | Sistema | Média | RF-E10.1, RF-E4.4 | Reunião de discovery - produtos nuree 29/07 | Ver a maturidade por dimensão e a geral após as respostas. |
| RF-E10.3 | O sistema deve permitir gerar o plano de ação a partir das dimensões de menor maturidade, com itens acompanhados como tarefas. | Admin | Média | RF-E10.2, RF-E3.1 | Reunião de discovery - produtos nuree 29/07 | Gerar plano a partir das dimensões fracas e acompanhar os itens como tarefas. |
E11 — Registrar presença em eventos e emitir certificados¶
Para formações presenciais. Sem pagamento na plataforma.
| ID | Requisito | Ator | Prioridade | Depende de | Fonte | Verificação |
|---|---|---|---|---|---|---|
| RF-E11.1 | O sistema deve registrar a presença do cliente em eventos por check-in (QR/scan), associando a participação. | Cliente | Média | RF-E1.3 | Reunião de discovery - produtos nuree 29/07 | Escanear registra a presença do cliente no evento. |
| RF-E11.2 | O sistema deve gerar um relatório de presença exportável para o cliente. | Admin | Média | RF-E11.1 | Reunião de discovery - produtos nuree 29/07 | Exportar a lista de presença de um evento. |
| RF-E11.3 | Quando um cliente conclui a jornada (cumpre os critérios de conclusão — presença em eventos, trilhas e quizzes concluídos), o sistema deve conceder um certificado em PDF, pelo mesmo mecanismo de concessão dos selos. | Sistema | Baixa | RF-E11.1, RF-E7.4, RF-E8.2 | Reunião de exploração de arquitetura 02/08 | Concluir a jornada concede o certificado em PDF. |
E12 — Trocar documentos por empresa¶
Repositório de arquivos por empresa, tipo mini-drive: pastas e envio/recebimento com o remetente visível (Nuree ou empresa cliente). Levantado na exploração de arquitetura.
| ID | Requisito | Ator | Prioridade | Depende de | Fonte | Verificação |
|---|---|---|---|---|---|---|
| RF-E12.1 | O sistema deve armazenar documentos vinculados a uma Empresa, organizados em pastas com hierarquia. | Todos | Média | RF-E1.6 | Decisão de projeto | Criar pasta e guardar um documento nela. |
| RF-E12.2 | O sistema deve permitir enviar e baixar documentos dentro do escopo da empresa. | Todos | Média | RF-E12.1 | Decisão de projeto | Upload e download de um documento. |
| RF-E12.3 | O sistema deve registrar e exibir o remetente de cada documento, distinguindo se foi enviado pela Nuree (Admin) ou pela empresa cliente. | Sistema | Média | RF-E12.2 | Decisão de projeto | Um documento exibe quem enviou (Nuree/cliente). |
| RF-E12.4 | O sistema deve permitir criar, renomear e remover pastas. | Todos | Baixa | RF-E12.1 | Decisão de projeto | CRUD de pastas dentro da empresa. |
| RF-E12.5 | O sistema deve restringir o acesso aos documentos ao escopo da empresa/programa. | Sistema | Alta | RF-E1.6 | Decisão de projeto | Empresa não acessa documentos de outra. |
Requisitos não-funcionais¶
Aplicam-se ao sistema como um todo (sem ator específico).
| ID | Requisito | Prioridade | Fonte | Verificação |
|---|---|---|---|---|
| RNF-1 | Funcionalidades de estrutura e conteúdo devem ser configuráveis pelo admin sem novo deploy. | Alta | Reunião de discovery - produtos nuree 29/07 | Criar formulário/jornada/trilha novos sem alterar código. |
| RNF-2 | O sistema deve isolar os dados entre empresas/programas em toda consulta. | Alta | AGENTS.md | Nenhuma consulta retorna dados fora do escopo. |
| RNF-3 | O sistema deve proteger o acesso com JWT (access + refresh), RBAC, rate limiting, CORS restrito e validação de entrada. | Alta | Decisão de projeto | Testes de autenticação, autorização e limites de borda. |
| RNF-4 | O sistema deve tratar dados de Mergulho e diagnóstico como sensíveis, com acesso restrito por escopo e política de retenção. | Alta | Inferência | Dados sensíveis só acessíveis ao escopo autorizado. |
| RNF-5 | A interface, o domínio, as rotas e a copy devem estar em português. | Alta | AGENTS.md | Revisão de idioma. |
| RNF-6 | A interface deve respeitar contraste, foco visível, prefers-reduced-motion e rótulos aria em português. | Média | PRODUCT.md | Auditoria de acessibilidade. |
| RNF-7 | A API deve expor um contrato REST/OpenAPI estável, apto a servir um futuro app mobile. | Média | Decisão de projeto | Spec OpenAPI publicada e versionada. |
| RNF-8 | O sistema deve ter backups automáticos do banco e da mídia, com cópia off-site. | Alta | Decisão de projeto | Restauração de backup validada. |
| RNF-9 | Toda exclusão/desativação é soft delete: o registro é marcado como excluído (isDeleted) e retido por ~3 meses antes do hard delete. | Alta | Decisão de projeto | Registro "excluído" some da UI mas persiste no banco; hard delete após ~3 meses. |
Restrições de projeto¶
| ID | Restrição | Fonte |
|---|---|---|
| RC-1 | O backend é uma API dedicada NestJS (REST/OpenAPI), substituindo as Server Actions. | Decisão de projeto |
| RC-2 | Infra self-hosted em VPS via Docker Compose: Postgres + Prisma, Redis + BullMQ, MinIO (S3), Caddy. | Decisão de projeto |
| RC-3 | Sem BaaS e sem processamento de pagamentos na plataforma. | Reunião de discovery - produtos nuree 29/07 / Decisão de projeto |
| RC-4 | Módulos se comunicam por event bus de domínio; trabalho assíncrono roda em worker. | Decisão de projeto |
| RC-5 | Integrações externas: WhatsApp (régua) e Google (login OAuth + Calendar). | Decisão de projeto |