Разработка технического задания. Что это такое, зачем оно нужно, с чего начать и как должно выглядеть? Как правильно составить техзадание

Данный текст был создан сугубо ради существования постоянной ссылки, которую бы сам автор, да и все вы - могли бы смело отправлять своим будущим заказчикам, коллегам, родственникам и знакомым в виде стандартизированного ответа на вопрос: «А надо ли мне ваше ТЗ и вообще что это?»

Как говорится - «вместо тысячи слов», поскольку каждый раз евангелистить по 4-5 часов в скайпе на данную тему становится уже утомительным, а общемировая тенденция подсовывать под определение «Технического задания» откровенную ерунду с годами все только усиливается.

Проблема

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

Техническое задание - исходный документ на проектирование технического объекта (изделия). ТЗ устанавливает основное назначение разрабатываемого объекта, его технические характеристики, показатели качества и технико-экономические требования, предписание по выполнению необходимых стадий создания документации (конструкторской, технологической, программной и т. д.) и её состав, а также специальные требования. Техническое задание является юридическим документом - как приложение включается в договор между заказчиком и исполнителем на проведение проектных работ и является его основой: определяет порядок и условия работ, в том числе цель, задачи, принципы, ожидаемые результаты и сроки выполнения. То есть должны быть объективные критерии, по которым можно определить, сделан ли тот или иной пункт работ или нет. Все изменения, дополнения и уточнения формулировок ТЗ обязательно согласуются с заказчиком и им утверждаются. Это необходимо и потому, что в случае обнаружения в процессе решения проектной задачи неточностей или ошибочности исходных данных возникает необходимость определения степени вины каждой из сторон-участниц разработки, распределения понесенных в связи с этим убытков. Техническое задание, как термин в области информационных технологий – это юридически значимый документ, содержащий исчерпывающую информацию, необходимую для постановки задач исполнителям на разработку, внедрение или интеграцию программного продукта, информационной системы, сайта, портала либо прочего ИТ сервиса.

Переводим на понятный язык

1) ТехЗадание - оно ставит задачу. А значит оно должно идти перед прототипом, скетчем, тестом, дизайн-проектом, потому что любой майндмеп, диаграмма потоков данных, архитектура - это уже выполнение некой задачи, это ответ на вопрос. А до того, как сам вопрос еще не задан, не сформулирован и не подписан всеми сторонами - любой ответ будет априори неправильным, не так ли? Итак, начало любой работы над любым проектом - это постановка задачи, а не судорожный поиск набросков десятка вариантов ее решения.

2) Собственно из первого пункта логично вытекает и новый - сам текст ТЗ обязан начинаться с главы «Цели и задачи», четко формулирующей, какие бизнес-цели преследует вся эта очередная попытка повысить энтропию в мире. Бесцельное задание, которое не решает никаких проблем, не достигает ничего и делается «от скуки» - официально не считается Техническим Заданием, а с этого момента находится в статусе «обычная бумажка».

3) Как же вам понять, решает ли предложенная дизайн-концепция или интерактивный прототип, а то и готовый к употреблению сайт - вышеизложенную задачу бизнеса? Ничего не поделаешь, придется опять вернуться к определению: «определяет… ожидаемые результаты и сроки выполнения. То есть должны быть объективные критерии, по которым можно определить, сделан ли тот или иной пункт работ или нет». То есть ТЗ без четких измеримых показателей в рублях, секундах, тонно-километрах или градусах Цельсия - быть не может. Бриф может, или прототип, или еще любая абсурдная бумажка, но только не ТехЗадание.

Отсюда делаем вывод, что в настоящем ТЗ обязательно должна быть глава «Порядок приемки и оценки», когда эти самые показатели берутся, замеряются, и стороны либо пожимают друг другу руки, либо отправляют проект на переделку.

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

Знает ли студия на аутсорсе бизнес-цели и измеримые показатели бизнеса лучше его владельца? Очевидно, что нет, а значит правильное ТЗ должно писаться представителями Заказчика, а не наемными работниками Исполнителя. Абсурд, когда исполнитель сам себе ставит задачу, затем сам себе придумывает способы ее оценки, и в конце сам же выставляет себе итоговую отметку за сделанную работу. В идеале такой «самодеятельности» быть не должно, хотя на практике повсюду именно так и происходит, в результате чего ТехЗадание и не оказывает нужной помощи проекту, слишком часто являясь по сути фиктивным документом. Не надо так.

5) Каждое внесение правок в готовое ТЗ должно стоить денег. Нельзя бесплатно и бесконечно править «Конституцию вашего проекта» только потому, что одна из сторон передумала, не выспалась, внезапно решила сэкономить и т.д. Цена каждого изменения в ТЗ должна также четко прописываться заранее в соответствующей главе.

Кстати, по идее точно также каждая правка в дизайне или внесение изменений в список страниц или функций должна иметь четкую цену, которая оплачивается заранее, до начала внесения данного изменения. Лично я предлагаю любую редактуру утвержденного ТЗ оценивать в 30% от всего бюджета проекта, но вы можете поступать иначе.

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

Итак: Что делаем? Для чего? Как поймем, что сделали? Сколько стоит каждый пивот? - написанные на листочке ответы на все эти вопросы и являются «серебряной пулей», способной вытащить даже самый провальный проект.

Контрольные вопросы

А здесь перечислю ответы на самые часто встречающие вопросы от заказчиков:

1) Так что, на написание ТехЗадания может еще и официальный ГОСТ есть? - Да, даже несколько.

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

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

4) Вот вы и Википедия пишете, что ТЗ создается заказчиком. Но я не умею\мне некогда\просто не хочу его делать сам. Как же быть? - Отдать разработку ТЗ третьей стороне, вполне знакомой с вашим бизнесом, его задачами, целевой аудиторией и потребностями, и в то же время досконально осведомленной о всех этапах веб-разработки. Эта третья сторона станет неким «веб-нотариусом», то есть гарантом того, что исполнитель не занизит нужные вам показатели или не затянет сроки, и что заказчик установит достижимые метрики и на итоговой приемке не будет субъективно оценивать созданный продукт, на ходу изменяя зафиксированные ранее требования.

5) И что, если ТЗ является юридическим документом, то я потом могу засудить аутсорсера, не заплатить ему, заставить переделать все в десятый раз? - Если документ составлен правильно, указаны цели и методология оценки их достижения; если документ подписан сторонами и упомянут в Договоре (само ТехЗадание договором не является) - то конечно же сможете. А вот с обычным брифом, прототипами, арт-креатив-макетом, Безопасной сделкой на FL - уже нет.

6) Мне говорят, что работа будет вестись по какому то то ли скраму, то ли аджайлу; а значит архаичное ТЗ мне больше уже не нужно. Это так? - Посудите сами: вам называют непонятное слово, явно что-то маскирующее и вот уже на основании незнакомого вам термина предлагают отказаться от юридически грамотного и наполненного целями и метриками документа. Сам же agile никаких целей вроде «достичь не менее 10 000 посещений к концу года», или «достичь цифры более 25 заказов с сайта через месяц» - установить не может, это просто способ проведения совещаний и новой организации нерадивых сотрудников. Задумайтесь несколько раз: «А не пускают ли вам пыль в глаза?». На самом деле никакому новомодному скраму профессиональное ТЗ повредить не может, а вот помочь - обязательно.

Для начала, надо напомнить, что техническое задание (ТЗ) - официальный документ, являющийся неотъемлемой частью Договора на разработку сайта.

ТЗ содержит техническое обоснование разработки и требования, предъявляемые к проектируемому сайту (дизайну, навигации, способам представления информации); определяет сроки, стоимость, объем и порядок выполнения каждого этапа разработки.

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

На основании ТЗ принимаются или отклоняются претензии Заказчика к качеству работы Исполнителя, оплачивается готовая работа, оформляется акт приема-передачи.

bikeriderlondon / Shutterstock.com

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

В настоящем документе приводится полный набор требований по реализации сайта.

Заказчик и Исполнитель соглашаются

Подпись Заказчика и Исполнителя в настоящем документе подтверждает их согласие с нижеследующими фактами и условиями:

Исполнитель подготовил и разработал настоящий документ, именуемый Техническое Задание (ТЗ), который содержит перечень требований к выполняемым работам.
Заказчик согласен со всеми положениями настоящего ТЗ.
После утверждения ТЗ все предыдущие договоренности теряют силу и действуют только пункты данного ТЗ.
Заказчик не вправе требовать от Исполнителя в рамках текущего Договора выполнения работ либо оказания услуг, прямо не описанных в настоящем ТЗ.
Исполнитель выполняет только работы, указанные в данном ТЗ.
Все что выходит за рамки пунктов данного ТЗ, Заказчиком оплачивается дополнительно, на основании утвержденных сторонами дополнений к данному ТЗ.
Исполнитель приступает к выполнению работ по ТЗ, после: письменного утверждения ТЗ, получения всей необходимой информации указанной в ТЗ, получения необходимых материалов заказчика и выполнения пунктов оплаты.
Заказчик берет на себя обязательства, по завершению принять работу в течении 3-5 рабочих дней, оплатить работы по данному ТЗ в указанные в нем сроки, в случае если работы выполнены в полном объеме и в соответствии с ТЗ.
Заказчик не вправе требовать от Исполнителя соблюдения каких-либо форматов и стандартов, если это не указано в настоящем ТЗ.
Все работы по созданию сайта ведется на собственном хостинге Исполнителя. После завершения всех работ, переносится на реальный сервер для тестирования.
По окончанию работ, Исполнитель предоставляет консультации по администрированию в течение 5 рабочих дней, но не более получаса в день. Дополнительное время оплачивается отдельно, согласно действующих тарифов Исполнителя.
Все неоднозначности, выявленные в настоящем ТЗ после его подписания, подлежат двухстороннему согласованию между Сторонами. В процессе согласования могут быть разработаны дополнительные требования, которые оформляются дополнительным соглашением к Договору и оцениваются соответствующим образом.
Положения данного документа являются обязательными для разработчиков после его утверждения в установленном порядке.
ТЗ является средством верификации выполненных работ.

Статья по теме: Нововведения в плагине Google XML Sitemaps

Совместимость с браузерами

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

Internet Explorer (версия 8 и выше);
Mozilla Firefox (версия 3 и выше);
Google Chrome (версия 4 и выше);
Opera (версия 10 и выше).

Требования к компоновке страниц сайта

Текст должен быть читаем. Согласно статистике, минимальное экранное разрешение мониторов пользователей составляет 1024×768 пикселей. При таком разрешении все тексты на сайте должны выглядеть понятно и хорошо видны без использования горизонтальной полосы прокрутки. При разрешении, меньшем, чем 1024×768 появится горизонтальная полоса прокрутки.

Сайт также должен иметь ограничения и на максимальный размер, чтобы хорошо выглядеть на мониторах с высоким разрешением. Поэтому максимальная ширина сайта будет 1280×1024.

Требования к изменению содержимого сайта

Для удаленного администрирования (добавления, редактирования и удаления текстовой и графической информации) может использоваться бесплатная система управления контентом сайта (CMS), например WordPress. Но можно использовать и UMI.CMS (она более удобна пользователю для редактирования сайта, но сложнее для разработчика). Поэтому, если Заказчик пожелает использовать UMI.CMS, стоимость внедрения оговаривается отдельно, после утверждения дизайна. Ориентировочно она будет дороже на 50% от стоимости программирования.

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

Резюме

От того насколько подробно вы опишите задачи, стоящие перед разработчиком сайта, настолько проще будет сдавать проект. Вплоть до того что написать как открывается картинка во всплывающем окне, в какой она будет рамочке и будет ли она открываться с каим-то дополнительным эффектом. Так как очень часто заказчики, еще при создании сайта норовят вносить правки в текст, картинки и тому подобное, что собственно относится к совершенно другому этапу, который называется «Наполнение сайта» или «Обновление сайта».

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

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

Третий пункт - это требования, которые заказчик предъявляет к выполнению задания. Без этого пункта не обходится ни одно техническое задание. В нем должно быть четко прописано, что именно, и в какой срок хочет получить заказчик. Не нужно думать, что опуская сроки выполнения задания вы даете "свободу" исполнителю. Работать в условиях неизвестности очень сложно.

Техническое задание не должно быть слишком расплывчатым - ведь исполнитель может понять его неверно или не так, как требуется заказчику. В то же время, техническое задание не должно быть слишком подробным - в любом проекте должно быть место творчеству. Кроме того, если вы досконально знаете, как должен выглядеть ваш сайт, журнал или прибор - что мешает сделать вам его самому?

Видео по теме

Источники:

как написать тз

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

Вам понадобится

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

Инструкция

Цели . Это очень важный раздел, посвятите его обдумыванию для того, чтобы четко сформулировать цели вашего ресурса. Например, если вы задумали создать интернет-магазин, объясните будущему исполнителю, с помощью чего вы собираетесь прибыль. Это поможет исполнителю предложить вам решения, которые смогут по максимуму претворить в жизнь поставленные вами цели.

Целевая аудитория. Опишите в этом разделе аудиторию, которую вы рассчитываете привлечь. Это может не только помочь с выбором сервисов, но и в разработке дизайна.

Функциональные требования. Требования принципиально можно разделить на функциональные и не функциональные/специальные. Функциональные требования лучше описать в виде примеров их использования.

Стандарты. Опишите стандарты возможностей использования, например стандарты серии WAI, удобства использования, например, ISO/TR 16982:2002, а также другие стандарты общего назначения.

Системные требования. Перечислите системные требования, какие операционные системы должны поддерживаться, требования к памяти. Также сюда могут войти требования по отказоустойчивости, например, возможность восстановления системы после сбоя.

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

Безопасность. В данном разделе опишите необходимые методы шифрования данных, способы их передачи и хранения.

Пользовательский интерфейс. Опишите способ отображения элементов пользовательского интерфейса.

Видео по теме

Обратите внимание

Техническое задание обязательно должно быть детализированным. Между представлением (идеей) проекта и техзаданием очень большая разница.

Полезный совет

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

Источники:

E2E4, сайт

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

Инструкция

В структуру обязательно включите раздел «Общие положения». В них оговорите используемые в техническом задании и дайте их смысловую расшифровку – приведите глоссарий. Это позволит исполнителю и заказчику разговаривать на одном и исключит двоякое толкование основных понятий и определений.

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

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

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

В разделе «Риски» отразите факторы, которые могут повлиять на сроки исполнения работы или ее стоимость.

Видео по теме

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

Инструкция

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

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

Пропишите исходные материалы, которые потребуются для выполнения работы, их формат, а также каким образом и в какие сроки эти «исходники» будут переданы исполнителю. Все эти данные необходимо прописать до подписания , чтобы проект «не буксовал» из-за нехватки нужных материалов со стороны заказчика.

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

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

Видео по теме

Обратите внимание

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

Полезный совет

В творческих проектах целесообразно давать исполнителю простор для фантазии и креатива. Для продуктивной работы избегайте жестких рамок и приветствуйте появление новых идей.

Источники:

написание тз в 2018

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

Инструкция

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

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

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

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

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

Инструкция

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

Начинается оформление ТЗ с наименования Заказчика. Внесите в этот пункт полную информацию о фирме.

Затем внесите полные данные о компании-Исполнителе.

Следующий пункт очень важен: укажите четкие сроки выполнения заказа - дату начала и дату его завершения.

Затем укажите, каков бюджет проекта, его смета.

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

Цели сайта. От этого будет зависеть дальнейшая разработка структуры, сервисы и услуги сайта.

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

Функциональные и специальные требования. Функциональные удобнее привести в виде примеров того, как их будут использовать, а специальные оформить списком – это могут быть возможности подписки, специальных рассылок и др.

Стандарты. Этот пункт лучше обсудить с исполнителем или продвинутым другом-программистом.

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

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

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

Полезный совет

Техническое задание обязательно должно расписано очень подробно. Иначе это будет не ТЗ, а просто описание общей идеи.

Источники:

E2E4, сайт

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

Инструкция

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

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

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

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

Видео по теме

Полезный совет

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

Будьте предельно внимательны при составлении технического задания - в дальнейшем это поможет решить спорные моменты с заказчиком.

Техническое задание, или ТЗ, – это документ, подробно описывающий все пожелания и требования заказчика к проекту. Составление его позволяет избежать недомолвок и разногласий в процессе взаимодействия клиента и исполнителя. Кроме того, нередко грамотно составленное ТЗ сокращает сроки, необходимые для выполнения задачи.

Недавно ко мне обратились, чтобы я посоветовал стандарты для написания технического задания (ТЗ) на разработку автоматизированных систем (АС) и программного обеспечения (ПО). Вот думаю, сейчас зайду в Яндекс , найду подходящую статейку и отправлю её. Но не тут-то было! Одной статьи, где перечисляются стандарты для ТЗ, включая шаблоны и примеры готовых документов, я не нашел. Придется сделать такую статейку самому…

И так, основные стандарты, методологии и своды знаний, где упоминается ТЗ или SRS (Software (or System) Requirements Specification):

ГОСТ 34
ГОСТ 19
IEEE STD 830-1998
ISO/IEC/ IEEE 29148-2011
RUP
SWEBOK, BABOK и пр.

ГОСТ 34

ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы регламентирует структуру ТЗ на создание именно СИСТЕМЫ, в которую входят ПО, аппаратное обеспечение, люди, которые работают с ПО, и автоматизируемые процессы.

Согласно ГОСТ 34 техническое задание должно включать следующие разделы:

1. Общие сведения
2. Назначение и цели создания (развития) системы
3. Характеристика объектов автоматизации
4. Требования к системе
5. Состав и содержание работ по созданию системы
6. Порядок контроля и приемки системы
7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие
8. Требования к документированию
9. Источники разработки

При разработке ТЗ для государственных проектов Заказчики, как правило, требуют соблюдение именно этого стандарта.

ГОСТ 19

“ГОСТ 19.ххх Единая система программной документации (ЕСПД)” - это комплекс государственных стандартов, устанавливающих взаимоувязанные правила разработки, оформления и обращения программ (или ПО) и программной документации. Т.е. этот стандарт относится к разработке именно ПО.
Согласно ГОСТ 19.201-78 Техническое задание, требования к содержанию и оформлению техническое задание должно включать следующие разделы:

1. Введение;
2. Основания для разработки;
3. Назначение разработки;
4. Требования к программе или программному изделию;
5. Требования к программной документации;
6. Технико-экономические показатели;
7. Стадии и этапы разработки;
8. Порядок контроля и приемки;
9. Приложения.

Естественно ГОСТ 34 (и 19) уже устарели, и я не люблю их использовать, но при правильном интерпретации стандартов, можно получить хорошее ТЗ, см. Заключение.

IEEE STD 830-1998

Достаточно хорошее определение стандарта 830-1998 - IEEE Recommended Practice for Software Requirements Specifications дано в самом его описании:

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

Согласно стандарту техническое задание должно включать следующие разделы:

1. Введение

1. Назначение
2. Область действия
3. Определения, акронимы и сокращения
4. Ссылки
5. Краткий обзор

2. Общее описание

1. Взаимодействие продукта (с другими продуктами и компонентами)
2. Функции продукта (краткое описание)
3. Характеристики пользователя
4. Ограничения
5. Допущения и зависимости

3. Детальные требования (могут быть организованы по разному, н-р, так)

1. Требования к внешним интерфейсам
- 1. Интерфейсы пользователя
- 2. Интерфейсы аппаратного обеспечения
- 3. Интерфейсы программного обеспечения
- 4. Интерфейсы взаимодействия
2. Функциональные требования
3. Требования к производительности
4. Проектные ограничения (и ссылки на стандарты)
5. Нефункциональные требования (надежность, доступность, безопасность и пр.)
6. Другие требования

4. Приложения
5. Алфавитный указатель

На самом деле новичку достаточно трудно понять, что должно содержаться в данных разделах по вышеприведенной структуре (как и в случае с ГОСТом), поэтому нужно читать сам стандарт, который . , правда, на англ. языке.

Ну а кто дочитал до конца - тому бонус: пример ТЗ, который я писал много лет назад (сейчас уже просто аналитиком давно не работаю, да и другие более удачные примеры запрещает открывать на всеобщее обозрение NDA).

Презентацией Юрия Булуя Классификация требований к программному обеспечению и ее представление в стандартах и методологиях .
Анализ требований к автоматизированным информационным системам. Лекция 11: Документирование требований .
Правила составления Software requirements specification (читать вместе с комментариями)
Примеры ТЗ и другой документации по разработке АС для МЭР
ГОСТ-овский стиль управления . Статья Gaperton по правильной работе с ТЗ по ГОСТ
Шаблоны документов для бизнес-аналитиков из

От автора: Как написать техническое задание (тз) на разработку сайта ? Тема достаточно обширная, и в рамках одной заметки ее сложно разобрать на все 100% (если вообще это возможно). Но общие положения, о том что нужно учесть и на что следует обратить сое внимание при составлении тз веб-сайта, я постараюсь изложить достаточно подробно.

Итак, техническое задание на разработку сайта

Техническое задание составляется для разработчика. На тз нужно ссылаться при составлении договора между заказчиком и исполнителем. Должна быть оговорена ответственность за невыполнение или некорректное выполнение пунктов и сроков с обеих сторон. Но самое главное (на мой взгляд), для чего создается техническое задание, так это для ускорения процесса разработки проекта .

Давайте проанализируем такой пример:

Предположим, что Вам на сайте, где-нибудь с боку нужен календарь. Казалось мелочь. Но чем подробнее вы опишите его функционал, тем быстрее получите результат.

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

JavaScript. Быстрый старт

Предположим, вам нужен последний вариант (с возможностью перелистывать месяцы и годы) с подсветкой текущей даты. Вы в техническом задании указали: «в боковой панели нужен календарь». Вам делают первый вариант (просто показывает числа по дням недели текущего месяца).

Что мы имеем. Исполнитель пункт тз выполнил, а вы хотели совсем иное. Вроде все в соответствии, никто не виноват, до конфликта не дошло, но самое главное потеряны время и деньги .

Это пример всего-то банального календаря.

А если придется переделывать что-то серьезнее, на переработку чего времени требуется не полдня, как в случае с календарем? Исполнитель возится с вами, хотя мог бы завершить ваш проект и начать новый.

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

Из каких пунктов обычно состоит техническое задание?

Давайте представим, что вы владелец некоторой компании или фирмы. Ваша компания занимается выпуском какой-либо продукции, и ее реализацией. У Вас есть покупатели. Вы сотрудничаете с продавцами (магазинами и интернет магазинами), сервисными центрами, потребителями продукции. Или же Вы делаете ресурс для такой компании и Вам нужно написать техническое задание.

Независимо от того в какой роли Вы выступаете, первое, чем нужно заняться перед составлением технического задания на создание дизайна сайта – это изучить структуру организации, то чем она занимается, номенклатуру, характеристики и вообще все, что связно с продукцией и с компанией. От того, насколько глубоко заказчик вникнет в суть происходящего на предприятии, зависит и то, что будет происходить на ресурсе. Поэтому тут задача обоюдная: заказчик должен как можно подробнее рассказать о предприятии, а исполнитель хорошенько вникнуть в суть происходящего.

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

Поехали по пунктам.

Описание

Здесь можно в пару предложений написать о предприятии, чем занимается. Что – то типа вступление сделать.

для кого — целевую аудиторию:

потенциальные покупатели

продавцы продукции (магазины, интернет-магазины)

сервисные центры

партнеры (фирмы)

потребители продукции (тот, кто уже купил)

Для чего нужен сайт:

Для повышения имиджа компании

Для увеличения продаж

Для удобства клиентов

Корпоративный

Сайт – визитка

Интернет магазин

Языковые версии:

Английский

Сайт должен решать какие-то задачи. Соответственно далее двигаемся по целям и задачам.

Цели и задачи

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

Потенциальные покупатели продукции.

Цель: привлечь больше покупателей и убедить сделать первую покупку, помочь сделать выбор.

Необходимо решить задачи:

Дать качественную, исчерпывающую информацию о продукции, дополнительных услугах, гарантии, сервисе, методах выбора.

Дать информацию о салонах-магазинах

Дать информацию о розничной торговой сети

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

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

Теперь перечисляем модули.

Функционал сайта

Для того чтобы перечислить функционал, нужно решить что ему необходимо:

Нужна ли регистрация

Нужен ли закрытый раздел (только для зарегистрированных пользователей)

Нужна ли форма обратной связи

И т.д. и т.п.

JavaScript. Быстрый старт

Изучите основы JavaScript на практическом примере по созданию веб-приложения

После того, как все это описали, мы подбираемся к самому главному и интересному. Конечно, вся проделанная выше работа очень важна, но теперь становиться еще «жарче».

Описание функционала

На данный момент мы знаем для кого сайт, какие цели и задачи он должен выполнять, его дополнительные функциональные возможности.

Настало то время, когда нужно всю собранную информацию привести в систему и красиво уложить. Чтобы облегчить задачу и не изобретать велосипед, можно посмотреть ресурсы схожей тематики. Что-то перенять у них, посмотреть и опробовать их функционал и то, что показалось неудобным, попытаться улучшить на своем проекте. В принципе, посмотреть сайты схожей тематики можно (а если нет опыта, то даже и нужно) в самом начале составления технического задания.

Предлагаю начать с пунктов меню. В нем нужно отобразить основные страницы и позаботиться о том, чтобы каждый из посетителей быстро нашел информацию для себя. А посетители – это наша целевая аудитория. Меню будет включать много пунктов, поэтому будет в виде выпадающего списка.

Для начала нужно рассказать о компании. Тут могут быть страницы о компании, история компании, контакты, отзывы.

Естественно должен быть пункт меню «продукция», с подпунктами «каталог продукции», «релизы», «отзывы о продукции».

В общем как расписывать надеюсь понятно. Представлю конечный вариант возможного меню:

о компании

история компании

контакты

продукция

каталог продукции

отзывы о продукции

служба сервиса

гарантийное обслуживание

послегарантийное обслуживание

потребителю

покупка и доставка

пользование

о сервисе

магазинам и интернет магазинам

фотографии продукции

Часто задаваемые вопросы

сервисным центрам

Как стать сервисным центром

Часто задаваемые вопросы

партнерам

приглашение к сотрудничеству

Часто задаваемые вопросы

С меню вроде разобрались. Теперь нужно расписать, что будет на каждой странице и как это все в целом работает. Плюс предоставить приблизительный макет. Его можно нарисовать на листке бумаги карандашом, отсканировать и прикрепить к техническому заданию. Единственное, что скажу – не ограничивайте фантазию дизайнера, набросайте в самом общем виде.

Эта часть меняется в зависимости от того, как вы хотите видеть вашу страницу. Может вверху не нужно столько баннеров, возможно вверху нужно указать контакты (адрес, телефон, факс), может в виде иконок «карта сайта», «главная», «контакты». Может, новости Вам слева не нужны, а «акции и релизы» показывать слева.

Главное теперь описать логику работы.

Логика работы

Я описывать буду исходя из рисунка выше.

Верхняя часть (header) остается неизменной на каждой странице. Новостная лента видна только на главной странице. На второстепенных страницах слева показываем подпункты меню того пункта, в котором в данный момент находимся (например если мы на странице «служба сервиса», то показываем ссылки на «гарантийное обслуживание», «послегарантийное обслуживание»). Соответственно и переходы по этим ссылкам ведут на соответствующие страницы. Здесь же, под подпунктами слева отображаем данные для связи с он-лайн консультантами (Skype, ICQ). Блок акции и релизы остаются на каждой странице. Подвал (футер) отображается один и тот же на каждой странице.

Примерно так описывается общая логика работы.

Теперь в нашем тз на разработку сайта, подробно описываем каждый обозначенный блок сайта. Например «Новостная лента».

«Новостная лента» из 10-ти последних новостей. Каждая новость должна состоять из заголовка новости, даты публикации, краткого начала новости (4-5 строк) и ссылки «читать полностью». При нажатии на ссылку «читать полностью» попадаем на страницу новостей. Новость, на которую попали, отображается на месте основного содержимого. Включает также заголовок новости, дату публикации. Слева так же отображается новостная лента. Новости за прошлые месяцы и года попадают в архив. То есть под новостями за текущий месяц отображаем «архив за (такой-то месяц или год)». При нажатии на ссылку «архив за (такой-то месяц или год)» вниз выпадает список новостей за соответствующий месяц/год.

Примерно так описываем работу каждого блока. Не забываем про случай с календарем. И самое главное нужно расписать работу каталога товара. Здесь я даю вам задание: попробуйте продумать и описать, как будет работать каталог. Свои варианты присылайте на e-mail. Лучший мы опубликуем.

Что еще должно быть? Неплохо было бы указать совместимость.

Совместимость

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

Если не владеете этими вопросами, то просто укажите браузеры, в которых сайт должен правильно отображаться. В остальном рассчитывайте на совесть исполнителя.

Заключение

В данной статье я не стремился показать, что именно так составляется тз и никак иначе. Делайте так и проблем не будет. Составить качественное техническое задание на разработку сайта – это скорее вопрос опыта . На первых парах составить грамотное техническое задание получиться далеко не у всех.

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

И не забывайте про задание!