ТЗ для web-разработчика

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

а тут это http://mdesign.ru/services/docs

Интересная статья со всех сторон, даже психологии немного есть: "Кстати - тут Вам и первый звоночек - если заказчик угощает - это хорошо, иначе - работайте по предоплате." =)

Наглядно и доступно, мне понравилось, но есть один момент:

Вы должны убедить заказчика в том, что именно Вы пишите ТЗ, и он за него должен заплатить. Если таковое не получилось - пришлите ему образец - пусть помучается, в итоге, если он ценит своё время - он таки согласиться на Ваши услуги.

Если заказчик - серьезный человек и действительно ценит свое время, а ваше ТЗ не произвело на него впечатление, то он, скорее всего, найдет другого специалиста, поэтому я бы не рекомендовал делать ставку на этот метод )

В остальном же, материал стоящий. )

Очень хорошая статья о том как писать ТЗ есть на старом добром вебмасконе

Вопросик, в чем структуру БД рисовали?

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

Прошу прощения за въедливость, но я бы ещё добавил, что в ТЗ не должно быть грамматических ошибок, таких как в этом тексте:
попробывать, распологаться.

Принцип отражен достаточно верно, но поверхностно. Насчет оплаты ТЗ - это верно, но не все заказчики могут на это пойти. Особенно, на периферии.

Кроме всего прочего я стараюсь (в последнее время) расписывать общий план проекта: что какие функции должны быть и как они должны работать. К этому плану прикладываю расширенную схему БД, в которой отмечаю функциональные взаимосвязи между полями: какие поля используються в тех или иных функциях и как.

Общий пример:

Понравилось как разработчику. Виртуально вам +1 :)

очень инетерсно

с удовольствием прочитал.

В закладки. Спасибо, интересно написано.

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

Возьмем на заметку.

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

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

А в чём нарисована диаграмма прецедентов

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

«Кстати — тут Вам и первый звоночек — если заказчик угощает — это хорошо, иначе — работайте по предоплате.»

Я наоборот угощаю сам. Ведь я же услуги предоставляю, а не заказчик.

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

Хотя, конечно, если заказчик настаивает на чае за свой счёт, это ему только в плюс.