Galogen - ГОСТ на ТЗ, это как библия для любого менеджера проектов, если хочешь этим заниматься, то тебе придется с ним подружиться. Автоматизацию лучше начать с шаблонирования. Потом группировать их для однородных предметных областей и т. д. Можешь сделать БД классификаторов ТЗ, а потом по ним дергать куски уже размеченного текста из БД или шаблонов. На платформе Office 2003 System, я думаю, это недурно выглядело бы.
Jimmy, полностью с тобой согласен. ТЗ - это начало всех разработок.
Alex Rootoff, в софтверных компаниях, да вообще, в любой организации где ведутся разработки, существует четкое разделение на технических писателей, разработчиков и кодировщиков, иногда первых двух объединяют в одном лице. Заказчик беседует с аналитиком, который выясняет у него все мыслимые и немыслимые требования, или же сам заказчик своими словами описывает свои представления о системе (внешнее описание). Затем технические писатели приводят внешнее описание в терминах ИТ и передают его проектировщикам/разработчикам -> кодировщики и т.д. См. классическую схему жизненного цикла программного обеспечения.
softwarer, ТЗ - это управляющий документ, относящийся к внутреннему документообороту компании. За такие дела выпинывают с работы. Я конечно понимаю, что процесс разработки это вещь творческая, но везде должен быть порядок...

softwarerВ одной из контор, куда посылал резюме, предложили либо писать ТЗ, либо реализовывать их. Попросил образец, прочитал, откланялся.
Ну, видимо клевый рабовладелец... в смысле работодатель :), что предложил сразу в руководящий отдел запихнуть... или нет? Или это у них относилось просто к канцелярии? А сколько платить хотели? Вообще интересный у тебя подход... Ну да ладно, кому что... Я понял твою идею, типа, необходимые инструкции и четкая формулировка по задачам... Неплохо, но фраза "Old School" тебе ничего не говорит? ;) Я с тобой согласен и того же мнения придерживаюсь, но... зачем то это придумали...