1. Писать должен тот кто разбирается и в ИТ и в бизнес процессах - это идеальный вариант. Но подходит для мелких компаний с технически продвинутым персоналом.
2. На практике - это тандем ИТ-шника и того, кто разбирается в конкретном бизнес-процессе (иногда таковых несколько человек - по каждому процессу - свой). Фактически ИТ-шник допрашивает с пристрастием разных людей, имеющих отношение к бизнес-процессу. И записывает с их слов, интерпретировав в технический язык.
Тут крайне важно, чтобы интервьюироваемые не перекладывали на ИТ-шника. Типа "ты же специалист, должен все знать". Я обычно отвечаю: "Вы хотите чтобы я ваши проблемы решил или свои".
Дело ИТ-шника понять и перевести на технический язык. Но ни в коем случае не самому описывать бизнес-процессы. Бизнес процесс должен описать тот, кто этим занимается.
Причем, важно!!!
Иногда начальники не очень хорошо представляют мелочи, которые будут важны для тех. задания.
Поэтому нужно общаться и с руководством и с простым сотрудником, которого затрагивает то, что описывается в тех. задании.
На самом деле ТЗ не всегда нужно.
Если заказчик согласен вечно платить почасовку - можно без ТЗ.
Это позволяет сэкономить кучу времени и быстро подстраиваться под изменения бизнеса.
Но это возможно только если заказчик может и согласен платить без ограничений.
Такое возможно, если сумма денег которые тратят на исполнителя - для заказчика копейки.
Или заказчик безоговорочно доверяет исполнителю (и исполнитель по карману заказчику)
Есть еще вариант -
делается примитивный прототип MVP
https://en.wikipedia.org/wiki/Minimum_viable_product
По нему оценивают и тех. задание составляют/уточняют.
Но делать такие вещи обычные заказчики отказываются,
только те, кто работает с большими и дорогими вещами - согласны.
Это серьезно уменьшает их риски.
Не совершайте ошибку - не пишите замороченными словами.
Нужно писать обычным человеческим языком.
ТЗ - это намного более простая вещь, чем обычно представляют.
Это просто описание человеческим языком всех нюансов.
Простой
