Тут написаны разные мысли по поводу того, как лучше составлять технические задания
Нафиг кому надо
Описание ТЗ хорошо начинать с описания того, зачем нужна модификация и какое место она должна занять в системе. Стоит перечислить модификации связанные с данной («похожа на», «зависит от»). Так же нужно указать кому она нужна (если управление требованиеми происходит отдельно, то сослаться на зарегистрированные требования, которые она должна закрывать)
Надо учитывать уровень подготовки программиста
Программистам с разным уровнем подготовки нужна разная степень разжеванности ТЗ.
Не стоит повторяться
(Принцип DRY — Don't repeat yourself)
Не очень хорошо, когда программисту приходится использовать 
специальные программы для того, чтобы выяснить, чем один кусок ТЗ отличается от другого.
Например, я встречал ТД на написание отчетов, в котором втречались повторения типа
...
- Сумма — сумма по полю стоимость по проводкам, в состоянии «Получено» по выбранному складу в выбранном диапазоне дат
- Количество — сумма по полю количество по проводкам, в состоянии «Получено» по выбранному складу в выбранном диапазоне дат
...
Иногда мне кажется, что буфер обмена — довольно вредное приспособление.
Надо использовать термины из системы
Надо называть вещи так, как они называются в системе. Программист может не знать синонимов. Если вам кажется, что готовых терминов не хватает (Например, это уменьшит количество повторений см. «Не стоит повторяться»)
Как это будет тестироваться
Стоит подумать о том, как модификация будет тестироваться — по крайней мере перечислить случаи на которые нужно обратить внимание. Программист может не знать о каких-то нужных галочках в настройках, переключение которых может привести к неработоспособности модификации
Надо использовать отступы и списки для структурирования информации
Также как программисты делают это в исходном коде. Сравните:
Если разноска складского журнала происходит при полной луне, надо оповестить об этом главного шамана компании, увеличить количество в складском журнале на 10 и выполнить проводку К666 – Д3.1459 в противном случае добавить проводку К666 – Д007
Если разноска складского журнала происходит при полной луне, надо:
- оповестить об этом главного шамана компании
- увеличить количество в складском журнале на 10
- выполнить проводку К666 – Д3.1459
в противном случае:
- добавить проводку К666 – Д007
Надо отделять задания от деталей предлагаемой реализации
Программист должен понимать, что является требованием а что — Вашим предложением по реализации.
Работа с изменениями: сохраняйте историю
Иногда время жизни технического задания довольно велико: в него вносят массу изменений и дополнений. Некоторые консультанты каждое изменение оформляют отдельным небольшим документом. В результате получается, что для того, чтобы узнать как должна работать система в данный момент, нужно собрать кучу документов, прочитать их в хронологической последовательности и состявить общую картину. Лучше так не делать:
- Ведите один документ
- Лучше хранить документ в системе контроля версий
- Набор изменений часто можно получить автоматически (например, Microsoft Word может сравнить два файла, а Tortoise SVN позволяет интегрировать эту возможность в контроль версий)
- Изменения лучше также вратце описать в багтрекере или в комментарии для системы контроля версий (кстати Tortoise SVN может проверять синтаксис на русском языке в этих комментариях)