FastInBox | Engenharia de requisitos
Especificacao de Requisitos de Software
Versao de consulta publica: 2.0 | Documento tecnico para banca
Esta pagina consolida os requisitos funcionais e nao funcionais criticos da plataforma, mantendo coerencia com a ERS base e traduzindo os pontos de implementacao para leitura objetiva de avaliacao.
1. Escopo funcional principal
- Autenticacao por perfil com rotas segregadas.
- Cadastro e gestao de pacientes por nutricionista.
- Criacao de pedido com multiplas marmitas e codigo unico.
- Revisao e pagamento pelo paciente sem fluxo paralelo.
- Painel da fabrica com mudanca de status operacional.
- Visao administrativa para governanca e acompanhamento.
2. Requisitos funcionais criticos (RFC)
| ID | Requisito | Criterio de aceite |
|---|---|---|
| RF-001 | Login por perfil com sessao valida | Usuario autenticado acessa somente seu escopo |
| RF-003 | Criacao de pedido com codigo unico | Pedido salvo com identificador nao colidente |
| RF-006 | Revisao e confirmacao de pedido pelo paciente | Status muda para aguardando pagamento |
| RF-007 | Pagamento integrado e liberacao operacional | Somente pago entra no fluxo de fabrica |
| RF-010 | Painel de producao para fabrica | Status atualizavel com persistencia de estado |
| RF-011 | Acompanhamento de status para cliente | Timeline coerente com ultima transicao registrada |
3. Regras de negocio mandatórias
- Nenhum pedido segue para producao sem confirmacao de pagamento.
- Codigo de pedido deve ser unico para evitar colisao de acesso.
- Transicao de status deve manter sequencia valida no fluxo operacional.
- Dados visiveis devem respeitar role e contexto do usuario autenticado.
- Acoes sensiveis devem gerar evidencias para auditoria futura.
4. Requisitos nao funcionais
| Categoria | Diretriz | Aplicacao atual |
|---|---|---|
| Usabilidade | Fluxos curtos, linguagem clara e feedback imediato | Telas por perfil com cards e passos objetivos |
| Confiabilidade | Persistencia de estado e previsibilidade de transicao | Store central com serializacao local na Sprint 1 |
| Performance | Tempo de resposta adequado para navegacao operacional | Build otimizado e entrega via CDN |
| Seguranca | Separacao de acesso e protecao de dados sensiveis | Rotas segregadas e evolucao prevista para backend |
| Manutenibilidade | Codigo modular e contratos tipados | Separacao por dominio e componentes reutilizaveis |
5. Matriz de rastreabilidade
| Requisito | Tela/Modulo | Evidencia |
|---|---|---|
| RF-001 | Login publico | Autenticacao por perfil funcional |
| RF-003 | Novo pedido nutricionista | Codigo gerado e exibido ao finalizar |
| RF-007 | Pagamento paciente | Status atualizado para pago |
| RF-010 | Dashboard fabrica | Kanban com drag-and-drop |
| RF-011 | Status paciente | Timeline refletindo etapa atual |
6. Lacunas conhecidas e plano
- Persistencia local substituida por banco relacional na proxima fase.
- Controle de acesso refinado por permissao de acao.
- Registro de auditoria persistente para eventos financeiros.
- Suite de testes de regressao para fluxos criticos.
A fase atual atende o criterio de validacao funcional do MVP. As lacunas sao conhecidas, documentadas e possuem rota de implementacao definida.
7. Casos de uso detalhados
| UC | Ator primario | Pre-condicao | Fluxo principal | Pos-condicao |
|---|---|---|---|---|
| UC-01 Login por perfil | Usuario autenticavel | Conta valida cadastrada | Seleciona perfil, informa credenciais e confirma | Sessao iniciada com escopo correto de permissao |
| UC-02 Criar pedido | Nutricionista | Paciente existente ou cadastrado | Define itens, observacoes e condicoes de entrega | Pedido salvo com codigo unico e status inicial |
| UC-03 Confirmar e pagar | Paciente | Pedido valido e visivel por codigo | Revisa dados, confirma e processa pagamento | Status alterado para pago e liberado para producao |
| UC-04 Produzir pedido | Fabrica | Pedido com pagamento aprovado | Mover pedido no kanban ate concluir entrega | Timeline operacional atualizada sem lacunas |
| UC-05 Monitorar operacao | Administracao | Dados de pedidos disponiveis | Consulta indicadores, filas e estados | Visao consolidada de desempenho e risco |
8. Priorizacao de requisitos (MoSCoW)
| Categoria | Itens principais | Justificativa |
|---|---|---|
| Must have | RF-001, RF-003, RF-006, RF-007, RF-010, RF-011 | Sem esses requisitos o fluxo de negocio nao fecha de ponta a ponta. |
| Should have | Telemetria de jornada e auditoria persistente | Aumenta governanca e reduz custo de analise de incidentes. |
| Could have | Alertas proativos e painis comparativos avancados | Agrega eficiencia operacional apos consolidacao do nucleo. |
| Wont have (fase atual) | Mobile nativo, automacao fiscal completa, predicao estatistica | Nao essencial para validacao funcional do ciclo academico. |
Essa priorizacao deve ser revisada em cada fechamento de sprint para refletir dados reais de uso e risco operacional.
9. Glossario tecnico
- Codigo unico do pedido: identificador nao colidente usado para acesso do paciente.
- Status operacional: estado atual do pedido na trilha producao-entrega.
- Evento financeiro valido: confirmacao de pagamento aprovada para liberar producao.
- Rastreabilidade: capacidade de reconstruir historico de acoes por pedido.
- Role: perfil de acesso com limites funcionais e dados permitidos.
10. Necessidades de stakeholders x requisitos
| Stakeholder | Necessidade sintetica | Requisitos relacionados |
|---|---|---|
| Nutricionista | Criar pedido rapido e acompanhar status | RF-001, RF-002, RF-003, RF-004 |
| Paciente | Revisar, pagar e entender o andamento do pedido | RF-005, RF-006, RF-007, RF-008 |
| Cozinha | Receber somente pedidos aptos e atualizar execucao | RF-010, RF-011, RF-017 |
| Administrador | Monitorar operacao, usuarios e comissoes | RF-012, RF-013, RF-014, RF-018 |
11. Criterios de aceite por jornada
| Jornada | Evento de aceite | Evidencia minima |
|---|---|---|
| Nutricionista | Pedido criado com codigo unico | Cadastro de paciente, itens e codigo visivel |
| Paciente | Pedido confirmado e pagamento registrado | Status atualizado e comprovacao de aprovacao |
| Cozinha | Pedido pago entra na fila correta | Kanban exibindo pedido e historico de mudanca |
| Administrador | Operacao consolidada e consultavel | Dashboard e filtros retornando pedidos e usuarios |
12. Requisitos de integracao e dados
- O gateway de pagamento deve devolver status verificavel e identificador de transacao.
- O modulo de autenticacao deve distinguir papel do usuario antes de liberar rota interna.
- O schema relacional futuro deve preservar codigo de pedido, status e trilha de eventos como campos auditaveis.
- Dados de paciente e pedido precisam respeitar minimizacao, segregacao por perfil e historico controlado.