Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 48
Я бы с удовольствием посмотрел на пример такого ТЗ, можете выложить?
присоединяюсь!
Примеры тут
К сожалению, не могу клиентские ТЗ выкладывать, т.к. в договоре есть пункты о неразглашении информации.
А если сделать типа Иванов Иван Иванович! Мне бы было тоже интересно посмотреть подобное реальное(придуманное от балды) ТЗ!
Software Requirements Specification — просто используйте это…
За ТЗ — зачет!
Но в целом как же меня достали такие вот студии со своим спамом и уверенностью, что они лучше всех знают каким должен быть web-сервис.
Но в целом как же меня достали такие вот студии со своим спамом и уверенностью, что они лучше всех знают каким должен быть web-сервис.
Я делюсь своими наработками с коллегами, что тут плохого? Если вам не нравится и у вас есть свои наработки, пользуйтесь ими.
>> Если вам не нравится и у вас есть свои наработки, пользуйтесь ими.
А еще лучше — делитесь ими с окружающими ))
А еще лучше — делитесь ими с окружающими ))
к сожалению в моем случае каждый договор и каждое ТЗ составляся индивидуально и не укладывается ни в один шаблон.
я еще раз говорю — в целом зачет! у меня в свое время вообще была идея создать проект с готовыми шаблонами ТЗ на все распространенные web-сервисы (гостевая книга, форум, блоги и пр). но времени на это банально нет(((
я еще раз говорю — в целом зачет! у меня в свое время вообще была идея создать проект с готовыми шаблонами ТЗ на все распространенные web-сервисы (гостевая книга, форум, блоги и пр). но времени на это банально нет(((
а я и написал ТЗ — зачет!
А реплика по поводу web-студий остается в силе.
А реплика по поводу web-студий остается в силе.
Зачем в очередной раз изобретать велосипед?
Есть ГОСТ 19, в котором есть требования к ТЗ
ГОСТ 19.201-78 Техническое задание, требования к содержанию и оформлению
Если Вы считаете, что ГОСТ Вам не подходит, то возьмите из этих требований то, что необходимо.
Есть ГОСТ 19, в котором есть требования к ТЗ
ГОСТ 19.201-78 Техническое задание, требования к содержанию и оформлению
Если Вы считаете, что ГОСТ Вам не подходит, то возьмите из этих требований то, что необходимо.
Мы так и сделали и в посте написали об этом.
Прошу прощения, но я не вижу соответствия между структурой ГОСТовского ТЗ и Вашего. В ГОСТе все выглядит логично, у Вас же набор пунктов, которые нужно выполнить.
На самом деле я не вижу основной смысловой части: «основание для разработки» и «назначение разработки» — это намного шире чем просто цели и задачи. А если бы Вы могли просчитать реальные «технико-экономические показатели», то, я думаю, и Вам и клиентам было бы только легче работать.
На самом деле я не вижу основной смысловой части: «основание для разработки» и «назначение разработки» — это намного шире чем просто цели и задачи. А если бы Вы могли просчитать реальные «технико-экономические показатели», то, я думаю, и Вам и клиентам было бы только легче работать.
Согласно ГОСТу, в ТЗ должно быть четко 8 разделов, помню, в вузе нас по этому сильно погоняли.
У вас, действительно, это, скорее, набор пожеланий, а не ТЗ.
Но, за то, что выложили — плюс.
У вас, действительно, это, скорее, набор пожеланий, а не ТЗ.
Но, за то, что выложили — плюс.
Выкладывать в rar и на файлообменнике с captcha — это как-то не очень технично. Лучше бы google docs.
Идеальное ТЗ — все о нём говорят, но никто его никогда не видел.
1. Как-то в общих положениях много лишнего.
2. «Требования к программному обеспечению сайта», забыли аппаратные требования, да и вообще раздел странный
3. Структура сайта и навигация — рядом бы.
А вообще мне не очень нравится, как-то размазанно.
На мой взгляд, дизайн следует разделять на оформление и логику, и описывать отдельно.
Всю программную часть описывать тоже в отдельном разделе.
Ещё не следует забывать, что веб-сайты можно разделить (грубо) на:
— презентационные
— информативные
— корпоративные (+ полноценные веб-приложения)
Каждый из типов требует немного разных подходов при написании ТЗ, соответственно шаблонов нужно несколько.
2. «Требования к программному обеспечению сайта», забыли аппаратные требования, да и вообще раздел странный
3. Структура сайта и навигация — рядом бы.
А вообще мне не очень нравится, как-то размазанно.
На мой взгляд, дизайн следует разделять на оформление и логику, и описывать отдельно.
Всю программную часть описывать тоже в отдельном разделе.
Ещё не следует забывать, что веб-сайты можно разделить (грубо) на:
— презентационные
— информативные
— корпоративные (+ полноценные веб-приложения)
Каждый из типов требует немного разных подходов при написании ТЗ, соответственно шаблонов нужно несколько.
Будут ли в ТЗ прописаны имеющиеся на странице блоки?
пример:
1. главная
1.1. блок меню
— представляет из себя тра-ля-ля
1.2. блок новости
— представляет из себя тра-ля-ля
1.3. блок футер
— представляет из себя тра-ля-ля
пример:
1. главная
1.1. блок меню
— представляет из себя тра-ля-ля
1.2. блок новости
— представляет из себя тра-ля-ля
1.3. блок футер
— представляет из себя тра-ля-ля
Уважаемый Александр, к сожалению это не ТЗ, а лишь общий план. Большинство требований (например требования к верстке) совершенно не зависят от клиента, а их действительно сложно сформулировать юридически грамотным языком, т.к. в юр. плоскости понятия «резиновая» и «статичная» верстка не применимы.
Что касается общих пунктов которые не хватает в вашем плане это:
— «ограничения» создаваемого сайта по нагрузке, максимальному кол-ву страниц, хостингу (требования к хостингу) и т.п.
— оговорки о том, что ТЗ содержит исчерпывающий перечень требований к сайту, никаких иных требований к создаваемому продукту Заказчик предъявлять не может.
При этом если ТЗ хорошо проработано, то как правило под каждого клиента оно меняется незначительно (10%-30%). А в идеале, все условия для конкретного клиента выносить в отдельный документ — эскизный проект или оформлять протоколом разногласий.
Что касается общих пунктов которые не хватает в вашем плане это:
— «ограничения» создаваемого сайта по нагрузке, максимальному кол-ву страниц, хостингу (требования к хостингу) и т.п.
— оговорки о том, что ТЗ содержит исчерпывающий перечень требований к сайту, никаких иных требований к создаваемому продукту Заказчик предъявлять не может.
При этом если ТЗ хорошо проработано, то как правило под каждого клиента оно меняется незначительно (10%-30%). А в идеале, все условия для конкретного клиента выносить в отдельный документ — эскизный проект или оформлять протоколом разногласий.
Это не ТЗ — это шаблон ТЗ
Совершенно не согласен, это не шаблон, это общий план по которому потом можно написать ТЗ, сделать шаблонное (типовое) ТЗ. Возьмем например шаблон справки 2НДФЛ, в случае вашего понимания шаблона, она бы выглядела так:
1. Данные налоговой инспекции
2. Данные человека
3. Данные о доходах
4. Подпись и печать
Как вы думаете, с какого раза человек правильно бы заполнил справку 2НДФЛ по такому шаблону? А подумайте какой удар по кредитным учреждениям нанес бы такой шаблон?
1. Данные налоговой инспекции
2. Данные человека
3. Данные о доходах
4. Подпись и печать
Как вы думаете, с какого раза человек правильно бы заполнил справку 2НДФЛ по такому шаблону? А подумайте какой удар по кредитным учреждениям нанес бы такой шаблон?
Насчет требований к верстке:
4.3. Требования к верстке страниц
1. html-документ должен соответствовать стандарту w3c в xHTML Strict, и быть сверстан с применением CSS.
2. html- документ сайта должен иметь блочную верстку (верстку div'ами), вложенные блоки следует отмечать отступами, для отступов использовать табуляцию.
3. html-код сайта должен быть удобен для понимания и структурирован, сложные и неоднозначные моменты прокомментированы.
4. Страница должна максимально идентично отображается во всех современных браузерах: Internet Explorer 7.0 и выше, Mozila FireFox 3.0 и выше, Opera 9.0 и выше, Google Chrome и при разрешениях монитора от 1024x768 до 1600х1200.
5. Все стили следует вынести в файл styles.css, определение стилей непосредственно на странице недопустимо.
6. Все java-скрипты следует хранить в папке /js/, вставка скриптов непосредственно в html-код недопустима, за исключением кода счетчика Google Analytics и ситуаций когда вынос скриптов в отдельный файл невозможен.
7. Результат требуется представить в следующей структуре файлов:
• /index.html – файл с вёрсткой страницы
• /styles.css – файл стилей сайта
• /images/ – каталог с графическими файлами дизайна сайта
• /js/ — файлы c js-скриптами.
8. Все названия стилей должны быть английскими (без русских слов на латинице).
9. Все тэги должны быть написаны в нижнем регистре.
10. У всех ссылок должен быть прописан параметр title="".
11. У всех картинок должен быть прописан параметр alt="".
12. Не следует использовать на странице заголовки h2 если нет заголовка h1 (это касается всех уровней заголовков).
13. Не использовать на странице более одного заголовка h1.
Кто вам кстати сказал, что ТЗ пишется юридическим языком? «резиновая» и «статичная» верстка — это уже зависит от дизайн-макета.
4.3. Требования к верстке страниц
1. html-документ должен соответствовать стандарту w3c в xHTML Strict, и быть сверстан с применением CSS.
2. html- документ сайта должен иметь блочную верстку (верстку div'ами), вложенные блоки следует отмечать отступами, для отступов использовать табуляцию.
3. html-код сайта должен быть удобен для понимания и структурирован, сложные и неоднозначные моменты прокомментированы.
4. Страница должна максимально идентично отображается во всех современных браузерах: Internet Explorer 7.0 и выше, Mozila FireFox 3.0 и выше, Opera 9.0 и выше, Google Chrome и при разрешениях монитора от 1024x768 до 1600х1200.
5. Все стили следует вынести в файл styles.css, определение стилей непосредственно на странице недопустимо.
6. Все java-скрипты следует хранить в папке /js/, вставка скриптов непосредственно в html-код недопустима, за исключением кода счетчика Google Analytics и ситуаций когда вынос скриптов в отдельный файл невозможен.
7. Результат требуется представить в следующей структуре файлов:
• /index.html – файл с вёрсткой страницы
• /styles.css – файл стилей сайта
• /images/ – каталог с графическими файлами дизайна сайта
• /js/ — файлы c js-скриптами.
8. Все названия стилей должны быть английскими (без русских слов на латинице).
9. Все тэги должны быть написаны в нижнем регистре.
10. У всех ссылок должен быть прописан параметр title="".
11. У всех картинок должен быть прописан параметр alt="".
12. Не следует использовать на странице заголовки h2 если нет заголовка h1 (это касается всех уровней заголовков).
13. Не использовать на странице более одного заголовка h1.
Кто вам кстати сказал, что ТЗ пишется юридическим языком? «резиновая» и «статичная» верстка — это уже зависит от дизайн-макета.
Это уже интереснее, тут есть что по обсуждать.
>> Кто вам кстати сказал, что ТЗ пишется юридическим языком? «резиновая» и «статичная» верстка — это уже зависит от дизайн-макета.
ТЗ пишется техническим языком, но при этом все термины должны быть расшифрованы чтобы избежать двусмысленностей и неверного тракования если не дай бог потребуется судебное разбирательство, в т.ч. и резиновая верстка, блочная верстка
По пункту 1.
Упоминая 'соответствовать стандарту w3c' нужно расшифровывать что это за организация, привести ее полное название, адрес сайта. Кроме того, xHTML какой версии? Еще было бы неплохо привести ссылку на сам стандарт.
>> Кто вам кстати сказал, что ТЗ пишется юридическим языком? «резиновая» и «статичная» верстка — это уже зависит от дизайн-макета.
ТЗ пишется техническим языком, но при этом все термины должны быть расшифрованы чтобы избежать двусмысленностей и неверного тракования если не дай бог потребуется судебное разбирательство, в т.ч. и резиновая верстка, блочная верстка
По пункту 1.
Упоминая 'соответствовать стандарту w3c' нужно расшифровывать что это за организация, привести ее полное название, адрес сайта. Кроме того, xHTML какой версии? Еще было бы неплохо привести ссылку на сам стандарт.
спасибо за шаблон! и да, о боже, на фотографии клавиатура как у меня:)
Для некоторых сайтов мы еще вписываем в ТЗ:
— Предполагаемая целевая аудитория сайта (для кого делаем сайт)
— Рамки проекта (в общих словах, что будет реализовано, какие будут «плюшки» и пр. Для тех, кому надо быстро понять в чем суть проекта, не перечитывая все XX страниц)
— Этапы работ и их сроки (или Вы их указываете в п.14 Порядок контроля и приемки работ?)
+ у нас в ТЗ есть большой раздел про SEO-требования: навигационные строки, структура и иерархия урлов, генерация метатегов и пр. Хотя это можно выносить и в «4.1. Требования к программному обеспечению сайта»
— Предполагаемая целевая аудитория сайта (для кого делаем сайт)
— Рамки проекта (в общих словах, что будет реализовано, какие будут «плюшки» и пр. Для тех, кому надо быстро понять в чем суть проекта, не перечитывая все XX страниц)
— Этапы работ и их сроки (или Вы их указываете в п.14 Порядок контроля и приемки работ?)
+ у нас в ТЗ есть большой раздел про SEO-требования: навигационные строки, структура и иерархия урлов, генерация метатегов и пр. Хотя это можно выносить и в «4.1. Требования к программному обеспечению сайта»
Сразу бросается в глаза отсутствие требований по нагрузке, но это уже отметили.
Ещё не мешало бы определить состав разрабатываемых и поставляемых компонентов (серверные скрипты, клиентские скрипты, документация и т. п.), хотя это, конечно, зависит от особенностей конкретного проекта.
Нужно ли писать ТЗ «юридическим» языком и стоит ли оговаривать в нём «исчерпывающие требования» — это зависит от ваших отношений с заказчиком, от других документов, от этапности работ и т. п.
Например, ТЗ может быть оформлено как приложение к договору. Тогда «юридическим языком» лучше составить договор, и в нём же оговорить этапы и сроки выполнения работ и возможности сторон по изменению требований. А в ТЗ — только собственно технические требования.
Что касается ГОСТ 19 или ГОСТ 34, то я бы не советовал браться за него без подготовки. Эти ГОСТы разрабатывались совсем в других условиях и совсем для других целей, они содержат множество ссылок на другие ГОСТы, ЕСПД и ЕСКД, и вообще больше ориентированы на «тяжёлые» проекты, а не сайты. Но их вполне можно использовать как чек-листы для самопроверки: а не упустили ли мы какой-то важный аспект в техническом задании.
Ещё не мешало бы определить состав разрабатываемых и поставляемых компонентов (серверные скрипты, клиентские скрипты, документация и т. п.), хотя это, конечно, зависит от особенностей конкретного проекта.
Нужно ли писать ТЗ «юридическим» языком и стоит ли оговаривать в нём «исчерпывающие требования» — это зависит от ваших отношений с заказчиком, от других документов, от этапности работ и т. п.
Например, ТЗ может быть оформлено как приложение к договору. Тогда «юридическим языком» лучше составить договор, и в нём же оговорить этапы и сроки выполнения работ и возможности сторон по изменению требований. А в ТЗ — только собственно технические требования.
Что касается ГОСТ 19 или ГОСТ 34, то я бы не советовал браться за него без подготовки. Эти ГОСТы разрабатывались совсем в других условиях и совсем для других целей, они содержат множество ссылок на другие ГОСТы, ЕСПД и ЕСКД, и вообще больше ориентированы на «тяжёлые» проекты, а не сайты. Но их вполне можно использовать как чек-листы для самопроверки: а не упустили ли мы какой-то важный аспект в техническом задании.
что бы тут не писали выше в комментариях, всё равно спасибо. Так как для начинающих любой пример — хорош, особенно если начинающие на знают как подойти к этому вопросу и с чего начать.
У многих небольших студий вообще нет никакого тех. задания если общая структура и брифы, и всё решается на усмотрение клиента и студии.
У многих небольших студий вообще нет никакого тех. задания если общая структура и брифы, и всё решается на усмотрение клиента и студии.
И какой объем у вас в итоге получается по такому шаблону?
Например: сколько страниц, какое количество прототипов b т.п.?
Например: сколько страниц, какое количество прототипов b т.п.?
Порядка 30 — 120 страниц, в зависимости от проекта. Прототипы не рисуем, т.к. создавать красивый и юзабельный дизайн сайта — это задача дизайнера. Мы описываем блоки на страницах и их содержимое, это гораздо быстрее чем рисовать прототипы и не связывает руки дизайнеру.
Такой уж некропост, прощу прощения, но ответ на вопрос интересует: как можно описать блоки на страницах в ТЗ, если еще неизвестно будет ли это отдельная страница, будет ли это отдельный блок или любой другой формат отображения?
К сожалению в посте так и не появилось актуального (живого) технического задания, чтобы можно было понять ваш подход к «заполнению» информацией страниц и блоков.
К сожалению в посте так и не появилось актуального (живого) технического задания, чтобы можно было понять ваш подход к «заполнению» информацией страниц и блоков.
Я для себя привык описания страниц делать все-таки на два радела:
1. Какие блоки и где на странице находятся;
2. Описание блоков.
Это вызвано тем, что на многих страницах блоки повторяются. Можно, конечно, копировать одно описание блока для каждой страницы. Но если на одной странице оно незначительно, но отличается, то читатель скорее незаметит его, т.к. «это я уже читал».
1. Какие блоки и где на странице находятся;
2. Описание блоков.
Это вызвано тем, что на многих страницах блоки повторяются. Можно, конечно, копировать одно описание блока для каждой страницы. Но если на одной странице оно незначительно, но отличается, то читатель скорее незаметит его, т.к. «это я уже читал».
Ты вообще крутые ТЗ пишешь! По www.rish.ru самое лучшие из того что я видел.
Удобнее будет отформатировать заголовки второго уровня правильно и привязать многоуровневый список к стилям заголовков. Шаблон довольно полезный.
Идея отраслевого стандарта очень интересная.
Но для этого нужно проделать большую методическую и просветительскую работу.
Прежде всего, важно показать, как взаимосвязаны пункты ТЗ с какими-то работами, зачем они вообще нужны.
Пока ваш список разделов вызывает больше вопросов, чем понимания.
NB: Состав и описание содержания и назначения разделов моих документов на проектирование небольших заказных программных систем.
Но для этого нужно проделать большую методическую и просветительскую работу.
Прежде всего, важно показать, как взаимосвязаны пункты ТЗ с какими-то работами, зачем они вообще нужны.
Пока ваш список разделов вызывает больше вопросов, чем понимания.
NB: Состав и описание содержания и назначения разделов моих документов на проектирование небольших заказных программных систем.
Лично мне хотелось бы увидеть:
— классное ТЗ (не шаблон) на веб проект (сайт, портал и т.д.);
— классное ТЗ на дизайн сайта…
Именно примеры готовые, а не шаблоны…
— классное ТЗ (не шаблон) на веб проект (сайт, портал и т.д.);
— классное ТЗ на дизайн сайта…
Именно примеры готовые, а не шаблоны…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Типовой шаблон технического задания на разработку сайта