ТЗ - это не первый этап, а второй.
Первый этап - обследование. Можете не верить, но на большинстве предприятий (сужу по тем, на которых я работал) нет вообще ни одного человека, который досконально знает, что происходит во всех подразделениях, как они между собой взаимодействуют. Может показаться, этой информацией владеет руководство, но это не так. Руководство занимется задачами стратегическими. Им совершенно безралично, в каком порядке заполняются и проходят обработку мелкие бумажки, какие при этом возникают проблемы и как они решаются.
Даже руководители конкретных подразделений, особенно сильно загруженные работой, и имеющие в подчинении достаточно грамотных подчиненных, зачастую разделяют функции до такой степени, что плохо представляют себе тонкости той работы, которой заняты их подчиненные.
Как вы полагаете, кто должен писать ТЗ?
Если вы думаете, что представитель руководства, то я вам сочувствую. Один раз я видел такое ТЗ - мне от него плохо стало.
Если думаете, что писать его должны программисты, то это тоже неправильно. Хотя, этот вариант все же лучше предыдущего.
Задача программистов - писать программы, знать досконально некоторое количество языков программирования и сред разработки. Если они начнут разбираться в тонкостях предметной области, они неизбежно отстанут как программисты. Ибо область эта очень и очень обширная. Писать ТЗ должен постановщик задачи. Это такой человек, который достаточно хорошо знает и представляет возможности различных программных инструментариев (хотя, возможно, не знает их так досконально как программист), но одновременно он является немного бухгалтером, немного финансистом, знает логистику, менеджмент, принципы документооборота и многое, многое другое. Если вы полагаете, что любой программист сходу сможет все это осилить, то либо вы супер-пупер-вундеркинд, либо просто ошибаетесь.
Так вот, пока на предприятии не появится человек, который досконально понимает, что, где и как происходит во всех деталях (и как должно происходить на самом деле в отличие от того, что имеется), никто нормальное ТЗ написать не сможет.
Обследование - это беседа с КАЖДЫМ участником процесса, сбор документов, с которыми сотрудники работают, выявление инфорационных потоков, расписывание выполняемых функций, алгоритмов принятия решений и т.д. и т.п. На коммерческом предприятии численностью 100 человек подобная работа на достаточном уровне делается за 2-3 месяца.
После обследования и перед составлением ТЗ собирается совещание, на котором постановщик должен высказать общую оценку того, как и что он видит себе в плане автоматизации. Если в процессе автоматизации ничего не будет запланировано изменить, значит постановщик задачи никуда не годится. Не бывает переход от ручной работы к автоматизированной без пересмотра схемы оборота информации.
На этом совещании крупным планом охватываются этапы автоматизации и бизнес-процессы, которые будут охвачены автоматизацией. Главное, что требуется знать - не должна производиться автоматизация ради самой автоматизации. Следовательно, все пожелания должны быть приняты во внимание, подвергнуты анализу, но не все из них обязательно выполнены.
Я просто приведу пример. Начальник хочет, чтобы у него на экране автоматически высвечивались цены всех конкурентов (бизнес-процессы ценообразования). Однако, при этом не оговаривается, откуда эта информация возьмется в компьютере. Если она должна быть в компьютере, значит какой-то сотрудник (подчиненный) должен ее туда заколотить. Необходимо оценить общие потери на выплату труда такому сотруднику, на электроэнергию, тепло, выдыхаемый углекислый газ в переполненном помещении и т.д. и т.п. и сравнить с теми плюсами, которые даст эта информация одному-единственному начальнику. Если плюсы в масштабах всего предприятия действительно перевешивают минусы, то затея имеет смысл. Что имеет смысл, а что не имеет - должен оценить постановщик. И на совещании высказать свою точку зрения в присутствии руководства.
Совместно принимается решение, какие процессы должны быть охвачены, а какие нет. В каком виде. В каком порядке.
После этого постановщик задачи садится и пишет ТЗ (примерно столько же времени, сколько обследование).
Потом ТЗ проходит согласование во всех подразделениях и в заключение у руководства (еще столько же времени).
И только после этого включаются в работу программисты. А вы говорите - 2 дня .

Дополнение.
На сайте http://www.interface.ru есть ряд весьма неплохих статей на эту тему. Особенно мне понравились статьи Акопянца Андрея. Его точка зрения очень близка к моей собственной.