Mesma convenção da especificação atual: cada requisito
tem identificador, prioridade e método de verificação (I inspeção, D
demonstração, T teste, A análise). Prioridade MoSCoW: M deve
(MVP), S deveria, C poderia, W não agora.
| ID |
Requisito |
Prior. |
Verif. |
UC |
| RF-3D-01 |
Ao clicar em Criar, o sistema deve oferecer a escolha entre Estúdio clássico e Editor de palmilha 3D, mostrando o saldo de créditos e o que cada modo entrega. |
M |
D |
UC-01 |
| RF-3D-02 |
O rascunho deve registrar o modo de criação (CLASSIC ou EDITOR_3D); rascunhos antigos são tratados como CLASSIC. |
M |
T |
UC-01 |
| RF-3D-03 |
Usuário sem créditos deve poder entrar no editor em modo preview (até 3 por mês), sem salvar. |
M |
T |
UC-02 |
| ID |
Requisito |
Prior. |
Verif. |
UC |
| RF-3D-10 |
O sistema deve apresentar um briefing guiado com: identificação do paciente (apelido/iniciais), numeração, comprimento e larguras, atividade principal, calçado, queixa/objetivo, observações. |
M |
D |
UC-02 |
| RF-3D-11 |
O agente IA deve retornar uma proposta de parâmetros no formato do contrato de geometria (JSON Schema versionado), com justificativa textual por parâmetro. |
M |
T |
UC-03 |
| RF-3D-12 |
Toda proposta deve passar por um validador determinístico que limita valores a faixas fabricáveis e registra cada ajuste feito. |
M |
T |
UC-03 |
| RF-3D-13 |
O sistema deve guardar a proposta original, a versão aceita/ajustada e quem aprovou (trilha de auditoria). |
M |
T |
UC-17 |
| RF-3D-14 |
Se a IA falhar ou exceder o tempo, o sistema deve oferecer parâmetros-padrão por numeração sem bloquear o fluxo. |
M |
T |
UC-03 |
| RF-3D-15 |
O prescritor deve poder pedir uma nova proposta alterando o briefing (consome revisão, não crédito). |
S |
D |
UC-03 |
| RF-3D-16 |
O sistema deve exibir aviso de que a proposta é sugestão e a decisão clínica é do profissional, exigindo confirmação explícita antes do primeiro salvamento. |
M |
I |
UC-03 |
| ID |
Requisito |
Prior. |
Verif. |
UC |
| RF-3D-20 |
O editor deve exibir o modelo 3D com rotação, zoom, pan e vistas pré-definidas (plantar, medial, lateral, posterior). |
M |
D |
UC-04 |
| RF-3D-21 |
O usuário deve ajustar os parâmetros por controles com valor numérico e unidade (mm, °), com atualização do preview em tempo real. |
M |
D |
UC-05 |
| RF-3D-22 |
Pés esquerdo e direito devem ser editáveis de forma independente, com ação espelhar de um para o outro. |
M |
D |
UC-06 |
| RF-3D-23 |
Parâmetros não disponíveis no plano devem aparecer bloqueados com indicação do plano que os libera. |
M |
D |
UC-05 |
| RF-3D-24 |
O usuário deve posicionar peças corretivas do catálogo no modelo 3D (Profissional+). |
S |
D |
UC-07 |
| RF-3D-25 |
O usuário deve definir zonas de densidade/dureza e padrão de preenchimento (Profissional+). |
S |
D |
UC-08 |
| RF-3D-26 |
O editor deve mostrar mapa de espessura/altura por cor e cotas principais. |
S |
D |
UC-04 |
| RF-3D-27 |
O editor deve oferecer desfazer/refazer na sessão. |
M |
T |
UC-05 |
| ID |
Requisito |
Prior. |
Verif. |
UC |
| RF-3D-30 |
Salvar deve criar uma revisão imutável numerada, com parâmetros, versão do contrato e miniatura. |
M |
T |
UC-09 |
| RF-3D-31 |
O sistema deve controlar o limite de 5 revisões por crédito e oferecer comprar +5 com 1 crédito. |
M |
T |
UC-09 |
| RF-3D-32 |
O usuário deve poder comparar duas revisões lado a lado com as diferenças de parâmetros (Profissional+). |
C |
D |
UC-10 |
| RF-3D-33 |
O usuário deve enviar uma revisão como pedido à fábrica, reaproveitando carrinho, checkout e ciclo de pedido atuais, sem consumir crédito. |
M |
T |
UC-14 |
| RF-3D-34 |
No pagamento do pedido, o sistema deve gerar para a fábrica a malha de fabricação e a ficha técnica PDF com cotas. |
M |
T |
UC-16 |
| RF-3D-35 |
O usuário (Profissional+) deve exportar a revisão em STL (par separado por arquivo) ou 3MF (com zonas), debitando 1 crédito. |
S |
T |
UC-13 |
| RF-3D-36 |
Arquivos exportados devem ficar disponíveis para novo download por link assinado e expirável. |
S |
T |
UC-13 |
| ID |
Requisito |
Prior. |
Verif. |
UC |
| RF-3D-40 |
O sistema deve exibir os pacotes e permitir a compra pelo link de checkout da InfinitePay. |
M |
D |
UC-11 |
| RF-3D-41 |
O crédito só deve ser liberado após webhook verificado de pagamento confirmado. |
M |
T |
UC-11 |
| RF-3D-42 |
O usuário deve consultar saldo, lotes, validades e extrato de consumo. |
M |
D |
UC-12 |
| RF-3D-43 |
O sistema deve expirar lotes vencidos e avisar por e-mail com 15 e 3 dias de antecedência. |
M |
T |
UC-19 |
| RF-3D-44 |
O admin deve conceder ou estornar créditos manualmente com motivo obrigatório (beta, cortesia, suporte). |
M |
D |
UC-18 |
| RF-3D-45 |
O admin deve cadastrar planos (créditos, preço, validade, direitos) sem deploy. |
S |
D |
UC-18 |
| RF-3D-46 |
O gestor da clínica deve convidar/remover membros e ver consumo por membro. |
S |
D |
UC-15 |
| RF-3D-47 |
O gestor da clínica deve salvar presets de parâmetros visíveis para os membros. |
C |
D |
UC-15 |
| ID |
Característica |
Requisito |
Meta |
Verif. |
| RNF-3D-01 |
Eficiência |
Taxa de quadros na manipulação |
≥ 30 FPS em celular intermediário de referência; ≥ 60 FPS em desktop |
T |
| RNF-3D-02 |
Eficiência |
Carregamento inicial do editor (código dividido, só baixa 3D se escolhido) |
≤ 3 s em 4G; pacote 3D ≤ 400 KB gzip |
T |
| RNF-3D-03 |
Eficiência |
Proposta da IA |
p95 ≤ 15 s, com indicador de progresso |
T |
| RNF-3D-04 |
Eficiência |
Geração de STL/3MF no serviço de geometria |
p95 ≤ 20 s por par |
T |
| RNF-3D-05 |
Correção funcional |
Divergência entre preview e malha de fabricação |
≤ 0,5 mm no contorno e alturas de controle; volume ±2% |
T (testes de ouro) |
| RNF-3D-06 |
Correção funcional |
Malha exportada |
Estanque (watertight), manifold, normais coerentes, unidade em mm |
T |
| RNF-3D-07 |
Confiabilidade |
Débito de créditos |
Idempotente (chave de idempotência); zero débito duplicado |
T |
| RNF-3D-08 |
Confiabilidade |
Falha de IA ou geometria |
Não perde o trabalho; estorno automático se a exportação falhar |
T |
| RNF-3D-09 |
Segurança |
Arquivo de fabricação |
Gerado apenas no servidor após débito; nunca exportável pelo cliente |
I/T |
| RNF-3D-10 |
Segurança |
Direitos do plano |
Validados no backend em todo endpoint de escrita |
T |
| RNF-3D-11 |
Privacidade (LGPD) |
Dados enviados à IA |
Sem nome, CPF ou contato do paciente; só dados clínicos mínimos |
I |
| RNF-3D-12 |
Auditabilidade |
Proposta × decisão |
100% das revisões ligadas à proposta, ao validador e ao aprovador |
I |
| RNF-3D-13 |
Usabilidade |
Escala SUS no beta |
≥ 70 |
A |
| RNF-3D-14 |
Usabilidade |
Primeiro projeto sem ajuda |
≥ 80% dos participantes em ≤ 10 min |
A |
| RNF-3D-15 |
Acessibilidade |
Controles |
Todos operáveis por teclado, com valor numérico editável e rótulos (WCAG 2.2 AA) |
I |
| RNF-3D-16 |
Compatibilidade |
Navegadores |
WebGL2 nas 2 últimas versões de Chrome, Edge, Safari e Firefox; fallback com mensagem clara |
T |
| RNF-3D-17 |
Manutenibilidade |
Contrato de geometria |
JSON Schema versionado; frontend, backend e serviço Python validam o mesmo schema |
I/T |
| RNF-3D-18 |
Manutenibilidade |
Cobertura |
≥ 70% nos módulos de créditos, validador e geometria |
A |
| RNF-3D-19 |
Custo |
IA por projeto |
Custo médio de tokens monitorado; alerta acima do teto definido pelos sócios |
A |
| RNF-3D-20 |
Retrocompatibilidade |
Rascunhos 2D |
Continuam abrindo e funcionando sem alteração |
T |
| RNF-3D-21 |
Observabilidade |
Rastreio |
Logs estruturados com id de projeto/revisão/job; sem dados pessoais |
I |
Desenvolvido e documentado por