Лучше всего учиться на
примерах. С другой стороны, если у вас есть макеты, дизайн и структура БД, то это фактически и есть ТЗ. Вам осталось минимум - записать это в форме удобной для исполнения и контроля. Разбейте систему на небольшие участки (формы, страницы и т.п.), это будут разделы вашего ТЗ. Наполните эти разделы тем, что у вас есть. Вот и готовое ТЗ.
Учтите, что если разработчик требует ТЗ, то у него есть какое-то представление об этом и если вы ему не угодите, то он скажет, что ТЗ плохое. С этим ничего не поделаешь. Хорошее ТЗ писать могут не многие, этому учатся годами. Если у вас нет столько времени, измените стратегию. Замените качественную формализацию общением. Так и скажите разработчику: "у нас есть вся нужная постановка, а детали, конкретика и вопросы при личном общении".
Опытный разработчик с хорошей точностью может оценить стоимость реализации макета (тем более с дизайном). Ему разжовывать все детали через ТЗ не требуется. Обычно все в ТЗ прописать не удается, не тешьте себя надеждами, что вот теперь-то все будет копейка в копейку. Всегда бывают разночтения, непродуманные моменты и изменения в ТЗ. Коммуникация между заказчиком и исполнителем обязательна.
Простой
