Um dev que se identifica como sênior deveria no mínimo fazer uma análise e te alertar sobre os pontos citados para saber se seriam tratados ou não.
De toda forma é sempre bom passar o máximo de informações para o dev, afinal quem sabe o que um software precisa é o cliente. No meu dia a dia recebo muita coisa "mastigada" onde um analista de requisitos já levantou 99% das tarefas. Nessas tarefas existem os critérios de aceite para que ela possa ser homologada pelo cliente.
Exemplo: Tarefa: Cadastrar Cliente
Critérios de aceite: [ ] Ao acessar o menu Clientes o sistema deve exibir o botão "Novo Cliente" [ ] Os campos nome, cpf, e-mail são obrigatórios [ ] Ao clicar em salvar, verificar se o cliente já está cadastrado com o cpf, se estiver, exibir uma mensagem de feedback "bla bla bla" [ ] Se houver falha na comunicação, exibir uma mensagem de feedback "bla bla bla"
...e assim por diante.
Esse tipo de levantamento me ajuda muito e evita que erros sejam transportados para produção.
No mais, esperto ter ajudado.
Confesso que a descrição do projeto poderia ser mais detalhada, mas também não houveram mais questionamentos por parte do desenvolvedor durante a negociação.
Já fiz documentações bem completas, chegando ao nível do desnecessário, com Casos de Uso, Diagramas UML, protótipos não funcionais etc.
Observei a publicação de outros projetos na plataforma do Workana e nenhum entra muito a fundo nos detalhes.