Дмитрий

Хорошее техническое задание для конкретного проекта - это результат хорошей работы специалиста управляющего проектом.
Залогом хорошего ТЗ является:
1) Работа на этапе лида
2) Встречи и сбор максимально необходимой информации
3) Обследование бизнес-процессов заказчика
4) Предварительное техническое обследование всех возможных проблемных моментов
5) Прототипирование - Мокапы, если там будет пару квадратиков, то скорее всего вас будет ждать фиаско
6) Терминология понятная заказчику с визуализацией позволяющей максимальной вероятностью однозначно воспринимать результат этапов (работы)
7) Подготовка необходимых приложений к ТЗ (Смета (перечень работ), Календарный план работ, Перечень макетов страниц, Гарантийные обязательства (подробно) и т.д.)
8) предварительное обследование внешних сервисов для интеграций
и т.д.
9) Написание ТЗ
10) Правильная оценка проекта
Вот когда вы хотя бы это сделаете, тогда можете смело свое ТЗ назвать хорошим.

Хорошее техническое задание -- очень обтекаемый термин. "Хорошим" можно было бы назвать техническое задание, отвечающее некоторым требованиям. А вот уже эти требования в зависимости от масштаба разрабатываемого продукта, методологии разработки, заказчика/исполнителя и других факторов могут сильно отличаться.

Так, например, если вы работаете с государственным или окологогосударственным заказчиком/исполнителем, весьма вероятно, вам придётся подготовить ТЗ в соответствии с требованиями ГОСТ-19 и 34 (в особенности ГОСТ 34.602-89 и ГОСТ 19.201-78), которые предполагают создание очень формальных и подробных документов.

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

Для какой-нибудь дизайнерской разработки (стиль, лого, графика), когда велика изначальная неопределённость, что же требуется сделать, лучшим вариантом может являться вообще достаточно общий бриф.

Резюмируя: определитесь с требованиями к ТЗ, а, отталкиваясь от них, уже можно искать какие-то варианты.

На самом деле, тз должно быть лаконичным и простым. Чтобы можно было легко понять назначение экранов/блоков/функций и их взаимосвязь. Этого достаточно, чтобы начать писать спеку.

Но саму спецификацию, где все экраны и бизнес-процессы декомпозированы до уровня классов/объектов, архитектуры бд, third-party решений и методов api, не напишет никто, кроме техлида или разработчика. А только это можно назвать хорошим ТЗ, которое взял и пилишь код.

Поэтому вопрос вряд ли имеет удовлетворяющий вас ответ.

Хороший план по подготовке ТЗ описан в моём блоге.
1. План создания технического задания (ТЗ)
2. Этапы проектирования сайта

Ufolob, единственным преимуществом MODX перед October остается, но ненадолго, количество готовых интеграций для e-commerce с популярными в СНГ сервисами.

Все остальное для решения задач типового проекта там есть. Я уже не раз здесь на Тостере приводил доводы в пользу October при его прямом сравнении с MODX. Посмотрите другие топики по тэгу OctoberCMS и наверняка найдете мои комментарии.

Если кратко. Забудьте MODX он устарел морально еще лет 5 назад и ничего хорошего для его будущего не предвидится. Они больше шести лет не могут выпустить мажорное обновление, которое хотя бы выровняло в техническом плане MODX с современными CMS.

Освоив October вы научитесь работать современными подходами в PHP-разработке и вплотную подступитесь к серьезной разработке на Laravel. А освоив последний, сможете выбриать наиболее подходящий инструмент для решения задачи.

Никогда не видел объемного и всеохватывающего ТЗ. Обычно это макет и куча правок к нему.