romaroСтоит ли писать ТЗ в форме руководства пользователя? Постановка задачи -> какие шаги нужно предпринять пользователю для ее решения.

ТЗ задает только ФУНКЦИИ, которые должен выполнять программный продукт.
Как эти функции будут реализованы, описывается в техническом проекте на программный продукт (техпроект утверждается заказчиком).
Иногда продвинутый заказчик может явно оговаривать в ТЗ инструмент, с помощью которого должен быть разработан программный продукт. Это косвенно определяет интерфейс пользователя.

Подробно опишите какая инфа на входе: первичные документы, виртуальные источники данных, датчики и тому подобное.
Что из них вводится в базу.

Какую инфу Вы хотите получить на выходе: отчеты, экранные представления. Какие из них будут использоваться часто, а какие - редко.

Какие расчетные формулы должны использоваться. Какие из этих формул могут менятся со временем.

Каковы диапазоны значений величин. Разрядность для числовых, длина для сроковых, интервал для дат.

Кто и что должен иметь право делать в программе.

Уровень подготовки пользователей программы.
Время работы пользователей.
Какое время простоя считается допустимым.
Каков допустимый отрезок времени, за котрый данные могут быть потеряны.
========
Если бы я получил такую инфу - то считал бы ее идеальным ТЗ
Это не ТЗ, а технический проект!
И всю эту работу должен выполнить исполнитель, изучив и описав предметную область заказчика и все его бизнес-правила (процессы).

ЮВ
И всю эту работу должен выполнить исполнитель, изучив и описав предметную область заказчика и все его бизнес-правила (процессы).

Да, именно исполнитель работы (договора), а не Заказчик.
А как он будет ее делать - силами собственных аналитиков, привлечет сторонние специализированные организации или иным путем - это его право.
А нажитый опыт - не всегда плохо, помогает избежать подводных камней.