Как написать правильное ТЗ для php программиста?

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

ГОСТы читал, на них ссылки кидать не надо

О, это целое искусство

Вообще грамотное описание use case'ов.

Можно исходить из модели MVC:

1. Модуль такой то
описание
1.1 Преставление такое то
описание
1.1.2 Действие такое то

Как то:

1. Админка
Админка предназначена для бла-бла-бла

1.1 Список юзеров
Управление юзерами системы

1.1.1 Вывод списка на экран
Это у нас таблица, в ней такие то колонки, доступны такие то действия. Нужна такая то функциональность.

1.1.2 Добавление юзера
Нужна такая то функциональность

1.1.3 Редактирование юзера
Нужна такая то функциональность

1.1.4 Удаление юзера
Нужна такая то функциональность

спасибо, какие ещё мнения?

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

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

MS Visio - нарисовать логику действия, нарисовать формы админки. Одна, только отрисованая форма, избавляет от переделки половины проекта из за "прекрасно, а как мне теперь добавить к этому товару картинку и показать ее в категориях, где сам товар быть не должен".

Да, желательно все диалоги нарисовать визуально с пояснениями. Это внесет существенную ясность в ТЗ. Или неясность, но тогда должны появиться вопросы.

изъянить чотко, грамотно и самое главное ПОЛНО суть задачи..чтобы потом не было "а тут можно это, а я думал что будет так"

А еще если после прочтения ТЗ у программиста возникло мало вопросов, то или хуевый программист, или хуевое ТЗ.

http://tdocs.su/1349

Dr.Syshalt писал:

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

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

Ну вообще это интерактивный процесс, который сам разработчик должен вести тогда. Что-то намулевал и показал тебе - "оно?". Это не дело клиента вообще, его дело - заплатить и на вопросы нужные ответить.

Но это, естественно, надо быть готовым оплатить тоже. Либо ты приходишь с готовым и расписанным всем - либо ищешь человека, который не говорит тебе, позевывая "ну, мне нужно точное ТЗ", а сам составляет все, тебе показывает и потом, после устаканивания, ты ему платишь за создание "чертежа", и он приступает к работе. Един в двух лицах. Если человек не может это сделать - ищешь другого. Заодно сэкономишь время на ожидании потом уже - ибо если человек грамотно спроектировать не сможет, он 100% не сможет и в код воплотить твою задумку.

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

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

Ну и соглашусь с Syshalt - если отдаешь программеру писать ТЗ, то на это уйдет время и деньги.

Хорошо идет ТЗ со скриншотами (если сайт)
Сразу 80% вопросов отпадает, так как на картинке все понятно.
Посему рекомендую сначала разрабатывать дизайн, с головой.
Думая какие ссылки где должны быть.
Какие кнопочки и так далее.
То есть получается что ТЗ какбы формируется на этапе дизайна.
Это гораздо продуктивнее, чем клевать мозг прогеру не имея диза.
Далее просто вставляешь скриншот страницы в Word и описываешь своими словами что там изображены, какой функционал.
Это самое простое ТЗ "на пальцах"