Pular para conteúdo

US1.2

Cadastro de Organizações Sociais (RF02)

História de Usuário

Como representante de uma organização social, quero cadastrar minha organização na plataforma informando CNPJ, dados institucionais e de contato para poder publicar vagas de voluntariado.

Rastreabilidade

Item Código
User Story US1.2
Requisito Funcional RF02 — Cadastrar organização
Característica de Produto CP01 — Gestão de Usuários e Entidades
Requisitos Não-Funcionais RNF01 (bcrypt), RNF03 (validação CNPJ), RNF04 (responsivo iOS/Android)
Release Planejada R1 — Fundação

Descrição

Implementar o fluxo de cadastro de organizações sociais, incluindo validação de CNPJ (RNF03), criptografia de senha (RNF01) e definição do status inicial como pending para moderação administrativa (RF06). O cadastro deve ser responsivo para iOS e Android (RNF04).

Critérios de Aceite (BDD / Gherkin)

Cenário 1: Cadastro com sucesso

Dado que o representante acessa a tela de cadastro de organização
Quando preenche CNPJ válido, razão social, nome fantasia, e-mail, telefone, senha segura, dados do responsável e submete o formulário
Então o sistema cria a conta com status pending, armazena a senha com bcrypt (RNF01), exibe mensagem "Cadastro realizado. Aguarde aprovação do administrador." e redireciona para tela de status de moderação

Cenário 2: CNPJ inválido

Dado que o representante inseriu um CNPJ com dígitos incorretos ou máscara inválida
Quando tenta submeter o formulário
Então o sistema exibe a mensagem "CNPJ inválido. Verifique os dígitos informados." e bloqueia o envio

Cenário 3: CNPJ já cadastrado

Dado que já existe uma organização cadastrada com o CNPJ "12.345.678/0001-95"
Quando um novo representante tenta cadastrar a mesma organização
Então o sistema exibe a mensagem "Este CNPJ já está cadastrado." e impede a duplicidade

Cenário 4: E-mail já em uso

Dado que o e-mail informado já pertence a outro usuário (estudante ou outra organização)
Quando o representante tenta finalizar o cadastro
Então o sistema exibe a mensagem "Este e-mail já está em uso." e solicita outro endereço

Regras de Negócio

  • O CNPJ deve ser validado matematicamente e quanto à formatação (RNF03).
  • O CNPJ e o e-mail devem ser únicos no sistema.
  • A senha deve ter no mínimo 8 caracteres (mesma regra do estudante, RNF01).
  • O status inicial da organização deve ser pending (aguardando moderação do admin — RF06). Após aprovação, muda para approved.
  • Os dados obrigatórios são: CNPJ, razão social, e-mail, telefone, senha e nome do responsável.
  • O cadastro cria automaticamente o OrganizationProfile vinculado ao User com role=organization.

Requisitos Técnicos

  • Backend: Django + DRF. Endpoint POST /api/v1/organization-profiles/ (ou equivalente no app users). Serializer deve validar CNPJ com biblioteca como pycpfcnpj ou validação customizada.
  • Frontend: React Native + Expo + NativeWind. Formulário de cadastro conforme padrão visual do projeto.
  • Segurança: Senhas com bcrypt (RNF01). CNPJ armazenado sem máscara no banco (apenas dígitos).
  • Performance: Resposta ≤2s (RNF02).
  • Responsividade: iOS e Android (RNF04).
  • Testes: pytest com factory_boy para criar OrganizationProfile em testes. Testar validação de CNPJ, duplicidade e status pending.

Referências de Design

Dependências

  • Relacionada a: #12 (Cadastro de Estudantes — mesma CP01)
  • Bloqueada por: N/A
  • Bloqueia: # (RF06 — Moderar organização)

Notas

  • A confirmação de cadastro por e-mail está fora do escopo do MVP (RF05 = Won't Have).
  • A logo e descrição da missão podem ser adicionadas posteriormente no gerenciamento de perfil (RF04).
  • Edge case: Se o CNPJ for válido matematicamente mas inexistente na Receita Federal, o sistema não precisa consultar a Receita no MVP — a moderação humana (RF06) é o filtro de legitimidade.
  • O campo "dados de contato" no RF02 pode incluir endereço, site e redes sociais; definir quais são obrigatórios para o MVP (sugestão: telefone e e-mail são suficientes para v1).

Definição de Preparado (DoR)

Item de Verificação (Universal) Evidência / Rastreabilidade Situação
A história está bem descrita e com critérios de aceite? Documentada e alinhada com o escopo do MVP. ✔ Sim
Possui protótipos de interface necessários? Interface mapeada e disponível no Figma da equipe. ✔ Sim
A história é independente o suficiente para ser entregue? Cadeia de dependências resolvida (vide Matriz MVP). ✔ Sim
Foi estimada pela equipe? Estimada utilizando o método ICE Score. ✔ Sim

Definição de Pronto (DoD)

Pergunta Fundamental (Universal) Evidência de Implementação Status
O código foi implementado e revisado? Pull Request aprovado e fundido na branch principal. ✔ Sim
Coerente com o protótipo validado? O layout segue os componentes e tokens de design. ✔ Sim
Passou nos testes necessários? Testes (unitários/integração) executados e aprovados. ✔ Sim
A documentação está atualizada? Atualizada no repositório de requisitos. ✔ Sim

Critérios de Aceitação (CA)

  • Cadastro com sucesso: O representante preenche CNPJ válido, razão social, nome fantasia, e-mail, telefone, senha e dados do responsável. A conta é criada com status "aguardando aprovação" e o representante vê a mensagem: "Cadastro realizado. Aguarde aprovação do administrador."
  • CNPJ inválido: Se o CNPJ tiver dígitos incorretos ou formato inválido, o sistema exibe "CNPJ inválido. Verifique os dígitos informados." e impede o envio.
  • CNPJ já cadastrado: Se o CNPJ já pertencer a outra organização na plataforma, o sistema exibe "Este CNPJ já está cadastrado."
  • E-mail já em uso: Se o e-mail informado já pertencer a outro usuário, o sistema exibe "Este e-mail já está em uso."

Acesso & Evidência

  • Código Homologado: Repositório Principal
  • Status de Conclusão: 100% Entregue (conforme Matriz de Completude).