Especifique o processo, não apenas o contrato
Um software blockchain sob medida combina componentes com responsabilidades diferentes. O contrato executa certas regras na rede; o backend conecta serviços e dados externos; a interface apresenta informações e solicita ações. Ainda há identidades, armazenamento, monitoramento e suporte. Pedir apenas um contrato inteligente costuma deixar decisões importantes sem responsável.
Comece com uma frase operacional: quem precisa fazer o quê, com qual informação e sob qual autorização? Depois descreva exceções. Um requisito como registrar aprovações é incompleto se não explica quem pode corrigir uma versão, contestar um resultado ou interromper o processo diante de uma suspeita.
Defina regras e poderes administrativos
Liste os estados permitidos e as transições entre eles. Diferencie consultar, registrar, aprovar, revogar e administrar. Uma função disponível na interface não pode ser a única barreira: as permissões precisam ser verificadas também no componente que efetivamente executa a operação.
A documentação de controle de acesso da OpenZeppelin diferencia administração por proprietário e permissões por papéis. São mecanismos técnicos, não uma decisão pronta de governança. A especificação deve identificar quem recebe cada poder, quem pode substituí-lo e o que acontece quando essa identidade é comprometida. Acrescentar administração também cria riscos que precisam ser avaliados.
Descreva backend, dados e dependências
Determine quais dados permanecem fora da rede, por quanto tempo precisam estar disponíveis e como serão recuperados. Para cada integração, documente formato de entrada, autenticação, limites, erros e comportamento quando o serviço externo não responde. Um dado informado por um sistema de origem não se torna verdadeiro apenas porque foi registrado em blockchain.
- Serviço de acesso à rede: disponibilidade e alternativa de consulta.
- Armazenamento: acesso, versionamento e restauração.
- Fila de tarefas: repetição controlada e prevenção de duplicidade.
- Bibliotecas: versões, licenças e responsabilidade pelas atualizações.
Inclua essas dependências na proposta; elas não desaparecem depois da entrega do código.
Exemplo hipotético: aprovação de laudos
Imagine um laboratório e uma indústria que precisam acompanhar versões de laudos fictícios. O requisito de contrato determina que apenas um revisor autorizado aprove uma versão registrada. O backend conserva o arquivo e relaciona seu identificador ao registro. A interface mostra versão, estado e responsável, sem expor o conteúdo a um usuário sem acesso.
Um critério de aceite seria: quando o revisor aprovar a versão dois, a versão um continua identificável como histórica, e um usuário comum não consegue aprovar pela interface nem por uma chamada direta. Outro critério exige que o sistema informe documento indisponível se o arquivo externo não puder ser recuperado.
Inclua qualidade e manutenção no pedido
Especifique tempos de resposta esperados sob uma carga definida, acessibilidade da interface, registros de auditoria e evidências de teste. Não use apenas expressões como rápido, escalável ou seguro: cada uma precisa de condição observável. Combine também quais falhas impedem a entrega e como divergências serão resolvidas.
O SSDF 1.1 do NIST, publicado em 2022, propõe práticas de desenvolvimento seguro ao longo do ciclo de vida e uma linguagem comum para conversar com fornecedores. Como aplicação prática, peça documentação de dependências, critérios de revisão e tratamento de vulnerabilidades. Esse pedido não equivale a certificar a solução nem elimina a necessidade de avaliação especializada.
Feche o escopo antes de estimar
Reúna regras, telas, integrações, restrições, testes e exclusões em um documento versionado. Indique quais hipóteses ainda precisam de laboratório e quem pode aprovar mudanças. Diferencie entrega de código, hospedagem, manutenção, revisão de segurança e treinamento. Quando uma dessas atividades não estiver contratada, registre quem deverá assumir a responsabilidade.
Uma próxima ação útil é revisar esse documento com operação e tecnologia antes de pedir orçamento. Na consultoria com William, a análise de requisitos pode envolver reuniões, pesquisa e documentação por horas combinadas. Isso não implica oferta automática de desenvolvimento, auditoria ou suporte permanente.
