Составление ТЗ для написания движка

Мэкс, спасибо за разъяснение ☝ Будем работать. Если у кого есть еще мысли, пожалуйста, высказывайте.

Мэкс, а все-таки: реально ли создать ТЗ, которое не пойдет в помойку через месяц после начала работ?

(мне кажется, что ТЗ - что-то вроде плана "Барбаросса": план был хороший, но жизнь внесла в него свои коррективы...)

Полное ТЗ нужно, когда разработка идёт с полноценным планированием наперёд.

Вот для того, чтобы жизнь не вносила коррективы и нужно ТЗ, чтобы сказать, что сорри, но этого нет в ТЗ (это я как программист смотрю). Со стороны заказчика это выгодно тем, что "что-то вы господа программеры тут намутили лишнего" :)

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

Мэкс, между

БТ - бизнес требованиями,

ТТ - техническими требованиями,

ЭП - экскиз проектом,

ТЗ - техническим заданием,

ТД - технической документацией

и т.д...

Короче между всем этим грань провести очень сложно... есть ГОСТ на ТЗ и мы его придерживаемся... еще есть какие-то ГОСТы на проектную документацию и т.д., но мы описываем и прилагаем к ТЗ мельчайшие подробности, что бы доля интеллектуального труда со стороны кодеров была минимальная... опять же, если рассматривать это в ключе "ТЗ на разработку проекта", то это одно... если рассматривать "ТЗ на кодирование", то это другое... у всех кого видел из серьезных все похоже более или менее на ГОСТ... остальные все (серьезные/авторитетные/известные) элитные упыри рожают это всё ДЛЯ ГАЛОЧКИ...

в общем какие требования такой и продукт... если мы в части дизайна системы требуем отсутствие операций записи на жесткий диск, отсутствие кук уровня всего домена и т.д., то на выходе получаем то, что мы спокойно можем массштабировать до бесконечности...

Если мы говорим про возможности СУБД, то мы описываем максимальное количество записей при которых это должно приемлимо работать... вот если все это описать, то упыри с парой десяткой запросов на генерацию одной страницы идут лесом.

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

Абсолютно реально. А как иначе выдержать сроки и бюджет проекта? Более того, если вы вносите изменения в ТЗ уже на этапе работ по ТЗ, то стоимость может повышаться непропорционально сильно, ибо приходится вносить изменения в план работы многих людей. Для Вашего случая есть понятие версионности. Т.е. ТЗ реализуется, но паралельно пишется другое ТТ для следующей версии.

ТЗ по ГОСТу - это точно, только для галочки. Мы такие штуки тоже делали, когда клиент требовал отдельное ТЗ для собственных программистов, а денег за него нормальных платить не хотел. В результате, в договоре указывалось, что ТЗ делается по ГОСТ N ( не помню номера на пямять, а искать неохота ) и выполняли только формальные требования этого ГОСТа. По такому ТЗ сделать что то путное силами кодеров практически невозможно :)

вот здесь посмотрите

http://www.dserg.com/requirements-specifications-links-2007-03-16.html

и другие материалы и ссылки в на этом сайте