НовыйЯКак поступают умные людим, чтоб вести соответствие изменений в коде с изменениями в ТЗ?
Ну во-первых, при долгой разработке вряд ли имеет смысл поддерживать "актуальное ТЗ" как монолитный документ, сил на это требуется много, а польза невелика. Удобнее работать с серией документов "последовательных изменений" - то есть задания на новые модули, описания изменений в старых.

Во-вторых, умные люди любят использовать трекер, то есть программу, позволяющую описать проект как серию относительно мелких задач и манипулировать этими задачами. Тексты задач в трекере нередко ссылаются на соответствующие пункты ТЗ, в других случаях дополняют и расшифровывают их. Так или иначе, любые изменения в коде делаются только в соответствии с задачей в трекере; это позволяет организовать весь последующий процесс вплоть до документирования сделанных и протестированных изменений (имеется в виду изменение пользовательской документации). Некоторые инструменты предоставляют средства, чтобы связать задачу в трекере и набор изменений, зафиксированный в VCS, но в любом случае никто не мешает писать номер задачи в комментариях к чекину; таким образом всегда возможно увидеть, по какой документации сделаны изменения, а также какие изменения внесены в рамках этой задачи.

В некоторых случаях трекер вообще становится основным "документом ТЗ", то есть основную массу задач начинают писать прямо в трекер, минуя стадию "многолистовых печатных документов".

pmleтак затраты на порядок снижают затраты на устранение ошибок
Да не сказал бы. Если у нас есть актуальное ТЗ (1000 страниц), и мы хотим внести в него изменения (новый модуль - 50 страниц, изменения старых модулей - 5 раз по 10 страниц), никто не будет читать изменённую версию документа, это нереально. Если задание на новый модуль ещё можно вписать в тысячестраничный документ и работать с ним, то разбросанные странички с поправками не будет читать никто и никогда; вся реальная работа - проработка, согласование с заказчиком, постановка задач исполнителям - будет идти с "маленькими документами изменений". Таким образом, внесение потом этих изменений в "полное актуальное ТЗ" - это отдельная работа, во время которой могут быть и будут сделаны свои, отдельные ошибки. Мало того; поскольку это полное ТЗ практически никто и никогда не будет читать, эти ошибки останутся очень надолго, до тех пор, пока кто-то с большим удивлением не попробует разобраться "как же оно" и не сравнит его текст с реальной системой.

InkelyadЯ, возможно, чего-то не понимаю, но использование Version Control для документации означает,
Ну в первую очередь оно означает, что в репозитории лежат бинарные файлы, с которыми особо ничего не сделаешь. Я наверняка чего-то не понимаю, но я, например, никогда не слышал об инструменте, который позволил бы мне сравнить две версии Visio-диаграммы и показать различия между ними :)

InkelyadВ случае необходимости "маленькие документы изменений" нам как раз инструменты Version Control сделают.
Ну, допустим, сделают (хотя я бы посмотрел на процесс в деталях). Дальше этот файл везём или высылаем заказчику, он вносит правки. Что делаем дальше? Запускаем совсем хитрую тулзу, которая по изменениям "маленького документа изменений" мержит изменения в основной документ? C учётом того, что его в то же время редактировали другие люди?

InkelyadТе работа должна выглядеть как Коммит в ТЗ/требования -> коммит в код/описывающую его документацию (одновременно! В одном коммите.), который это реализует.
Мм... эта идеальная модель представляется мне технологически проблематичной и организационно нереальной.

InkelyadЕсли поставить себе такую задачу, то можно выбрать себе текстовые форматы хранения исходников документации.
Если поставить задачу, то можно, конечно, и не такое :) Но это уже стопроцентный сигнал задуматься, стоит ли игра свеч. Признаться, я даже уверен в ответе на этот вопрос.

InkelyadОтсылаем заказчику линк на весь документ с правками в GoogleDocs (или на наш частный эквивалент).
Заказчик в грубой матерной форме просит дать нормальный doc-файл, в котором нет ничего лишнего. Напоминаю ещё раз: он совершенно не собирается читать тысячестаничное ТЗ и/или искать в нём нужные страницы. Ему нужно согласовать изменение на десять страниц, и именно их он хочет увидеть. А ещё он заказывает музыку. Во всяком случае заказчики, согласные работать с ТЗ в виде diff-а текстовых файлов, встречаются нечасто

InkelyadЗависит от. Та часть, которая "в коммите должен быть код и изменения в документацию" при известном желании реализуема.
Эта задача не самоцель. Вопрос не в том, можно ли её реализовать, а в том, сколько это будет стоить и насколько приблизит настоящие цели. Это отдельная большая тема... честно говоря, не готов сейчас развивать её во всей полноте, поэтому ограничусь довольно очевидной констатацией: документация, не соответствующая реализации, есть бесполезный мусор. С течением времени документация склонна в такой мусор превращаться. Чем больше документация по объёму/детализации, чем меньше она задействована в процессе разработки и чем больше пишется по факту - тем дороже стоит поддержание её в более-менее адекватном состоянии, соответственно тем резоннее звучит вопрос "а нужна ли нам такая документация за такую цену". Ответ, разумеется, зависит от деталей проекта, причём как от задачи, так и от команды.

InkelyadА аналитик нигде не ведет "текущее ТЗ" что ли?
А разве у нас не принято читать то, на что, по идее, отвечаешь? 13487408 , первое предложение.

Inkelyadя и не согласен. Последовательность "Получил/утвердил хочушку заказчика" -> вписал ее в "Текущее ТЗ" -> нагенерировал задач в трекере вида "сделать то, что описано в изменении ТЗ <номер коммита>" не выглядит уж очень трудоемкой.
Трудоёмкость, да ещё на пальцах - вопрос, конечно, спорный. Даже бесконечно спорный :) У меня на самом деле к этой последовательности больше другая претензия - связанная с тем, что результат этого процесса (то есть "текущее тз") никто не будет толком читать и использовать. А следовательно - это производство той самой мусорной, дезориентирующей документации. С этим можно в определённой степени бороться, например, обязать тестировщиков принимать задачи согласно именно этому "монолитному тз" - но это опять же довольно существенные дополнительные траты. А вопрос "ради чего" как висел, так и висит.

MyNiGooБуквально сейчас имею ситуацию, что требования фактически ведутся в Jira в виде багов, запросов на фичи, тасков и т.п. Пришел новый сотрудник, ему нужно знакомиться с системой, а собрать описание функционала какого-нибудь модуля невозможно,
Пришёл новый сотрудник - и в случае монолитного документа он как раз и огребёт все ошибки, которые в него заложены. Просто потому, что за два года, прошедших с предыдущего существенного изменения модуля - он первый, кто это читает - и вполне вероятно, последний. При этом практически наверняка куча мелких изменений таки прошла "через таски в джире" не затронув этого монолита, поэтому, натыкаясь на расхождение написанного в ТЗ и наблюдаемого в реальности, этот новый сотрудник не сможет решить, то ли это ошибка, то ли неизвестная ему и неописанная деталь.

Монолитный документ... раз ушла речь зашла о личном опыте, год назад я наблюдал такой "монолитный документ ТЗ". Высшей точкой бардака была упомянутая в нём функция - про которую никто не знал, кто и зачем её вписал, никто толком не понимал, как она должна работать (и ТЗ этого не расшифровывало), никто не мог высказать хотя бы обоснованное мнение, что же там должно происходить - но заказчик собирался принимать проект "по пунктам", и чтобы сдать, её надо было сделать. В итоге сделали практически пустую кнопку с правильным названием, так и сдали. Думаю, с тех пор её никто и не нажимал.

Использовать трекер, безусловно, стоит, но вести в нём всю документацию по достаточно крупному проекту - конечно, нельзя. Напомню то, о чём я говорил выше - задачи в трекере, по крайней мере связанные с достаточно существенными требованиями, должны ссылаться на постановку, при необходимости расшифровывать и дополнять её. Но для этого совершенно незачем иметь постановку в виде монолита; удобнее всего держать её в вики. И "новый сотрудник" при этом довольно легко входит в проект. Может быть не так хорошо, как в случае "монолит на блюдечке", но с гораздо меньшими затратами, нежели требуется на поддержание монолита в адекватном состоянии.

И напомню ещё раз, всё зависит от проекта. Для проекта в 5 разработчиков и проекта в 500 разработчиков требуется разный уровень документированности. Для заказной системы под конкретного заказчика требуется другой уровень документации, нежели для тиражируемого продукта. Итп.