Как составить техническое задание образец

Как правильно составить техническое задание по 44-ФЗ

Как составить техническое задание образец

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

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

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

Основные требования к техническому заданию

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

33 44-ФЗ предъявляет строгие правила к описанию объекта заказа и устанавливает порядок его формирования. Согласно ст.

33, к описанию закупаемого объекта устанавливаются единые требования, которым заказчик обязан следовать неукоснительно в процессе разработки техдокументации торгов.

Пример технического задания по 44-ФЗ, образец которого можно скачать ниже, продемонстрирует определенные правила, действующие в отношении описания объекта закупки:

  1. Описание предмета заказа должно быть составлено объективно. В ОЗ допускается включение технико-функциональных, качественных и эксплуатационных особенностей приобретаемых ТРУ.
  2. Разрабатывая описание ОЗ, работник контрактной службы заказчика имеет право использовать только ту терминологию, которая предусмотрена регламентом, закрепленным действующим законодательством.
  3. В описании ОЗ допускается использование чертежей, фотографий, эскизов, результатов тестовых испытаний и подобных сведений.
  4. Если в ТЗ определяется условие о предоставлении исполнителем образца приобретаемой продукции, то в закупочной документации необходимо обозначить время и место осмотра товарного образца.
  5. В том случае, если ОЗ — лекарственные препараты, то заказчику необходимо указывать непатентованные наименования, признанные во всем мире. Если такие наименования отсутствуют, то вносятся химические или группировочные наименования ЛП.

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

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

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

Образец технического задания по ГОСТу может быть использован не во всех случаях, то есть заказчику не обязательно при каждой закупке руководствоваться ГОСТом, стандартами или иными регламентами (п. 2 ч. 1 ст. 33 44-ФЗ).

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

При отсутствии ГОСТов и регламентов на товары, работы, услуги, для которых существует функционирующий рынок, заказчик вправе разработать описание на основании сведений производителей и иных качественных показателей, которые необходимы для конкретного предмета заказа (Письмо Минэкономразвития России № ОГ-Д28-9745 от 03.08.2016).

В том случае, если ГОСТ необязательный, но он указан в ТЗ тендера, он становится обязательным для обеих сторон контракта.

Далее представим образец формы технического задания по 44-ФЗ.

Скачать

Как составить техническое задание

Нормативными источниками для формирования ТЗ могут выступать:

  • отраслевые нормативы;
  • технико-технологические условия;
  • госстандарты;
  • методические разработки министерств и ведомств.

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

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

Техническое задание — это часть закупочной документации. В него должны быть включены следующие параметры:

  1. Сведения об организации-заказчике. Его юридический и фактический адрес, координаты для связи, банковские реквизиты и коды по Общероссийскому классификатору.
  2. Сведения о заказе. В техническом задании надлежит указать полное наименование предмета торгов с указанием всех используемых терминов, способ проводимой закупки (ч. 1 ст. 24 44-ФЗ), обоснование способа определения поставщика (ч. 5 ст. 24), источник финансирования.
  3. Описание ОЗ.
  4. Требования к упаковке товара и безопасности объекта заказа.
  5. Сроки поставки ТРУ.
  6. Гарантийный срок.
  7. Условия по сервисному обслуживанию, монтажу, пусконаладочным работам, обучению сотрудников грамотной эксплуатации поставляемой продукции (при необходимости).

При разработке условно можно выделить три этапа.

На первом, подготовительном, этапе необходимо определить потребность в приобретаемых ТРУ, рассчитать и обосновать НМЦК, описать предмет заказа.

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

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

Рекомендации по составлению технического задания

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

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

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

  1. Техзадание должно быть тесно взаимосвязано с инструкцией по заполнению заявки.
  2. Все термины, которые включены в техническое задание, должны быть упорядочены, а инструкция по составлению заявок должна легко читаться и адекватно восприниматься потенциальным поставщиком. При этом судебная практика расценивает заявки, затрудняющие восприятие и не содержащие соответствие объекта закупки и инструкции по формированию заявок, как ограничивающие конкуренцию.
  3. Специалисту надлежит указывать, когда значение диапазонного показателя не должно изменяться. Диапазонные показатели должны быть максимально приближены к реальности. Заказчик может определить диапазонный показатель как набор из минимального и максимального значений, а участник заказа выбирает конкретное значение в указанных рамках. Либо же заказчик должен определить, что значение диапазонного показателя не может изменяться, а потенциальный поставщик указывает в заявке диапазон в неизменном виде. Ошибки при установлении диапазонных показателей сводятся к неправильному или недостаточно четкому выбору между указанными альтернативами. При этом вариант «по умолчанию» — это первый вариант, когда участнику закупки нужно указать в заявке конкретное значение показателя.
  4. Все альтернативные значения показателей должны быть реальными.
  5. По общему правилу не стоит устанавливать требование о соответствии техническим условиям, это также признается судами ограничением конкуренции.
  6. Если заказчик устанавливает требования к цветовым характеристикам товара, то они должны быть обоснованными и целесообразными.
  7. Запрещается устанавливать требования к участнику заказа и его ресурсам (ч. 3 ст. 33).
  8. Запрещается закупать ТРУ, которые не соблюдают законодательные требования к энергоэффективности. Это грозит заказчику штрафными санкциями. Если в заказе присутствует необходимость изображения или эскиза, то лучше его предоставить в составе ТЗ.

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

Источник: https://gosuchetnik.ru/goszakupki/kak-pravilno-sostavit-tekhnicheskoe-zadanie-po-44-fz

Как правильно составить техническое задание: пошаговый алгоритм

Как составить техническое задание образец

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

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

Многие игнорируют факт написания детального технического задания, что в последствии приводит к недопонимаю, спорам, конфликтам и ссорам.

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

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

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

Для чего ТЗ заказчику?

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

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

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

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

Для чего ТЗ исполнителю?

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

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

Я не раз сталкивался с моментами, когда заказчик не хотел принимать работу, аргументируя неполным ее выполнением. Но поднимания первоначальное ТЗ оказывалось, что тех задач, о которых шла речь, вообще никто не ставил.

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

С чего начать составление грамотного технического задания

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

  • Общие положения технического задания

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

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

Чтоб не получилось путаницы, сразу расставьте все на свои места.

Рекомендуем прочитать: «Что такое вендинговый бизнес и как его начать?»

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

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

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

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

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

В общем, разжевали все до мелочей, а не только то, что касается дизайна.

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

  • Функциональные требования

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

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

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

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

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

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

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

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

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

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

Также должен быть отчет по факту выполненных работ. Что было сделано, сколько на это потрачено времени, с какими трудностями столкнулся исполнитель и т.д.

Если вы составляете договор, то пункт относительно ответственности будет в нем.

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

Как составить техническое задание: советы из личного опыта

И в конце это статьи, хотелось бы дать несколько советов исходя из собственного опыта составления и получения технических заданий.

  1. Техническое задание должно быть детальное. Не бойтесь описывать каждый элемент, каждый пункт, каждую кнопку. Все-все-все максимально детально пишите. Не бойтесь показаться дотошным. Уж лучше что-то несколько раз повторить и разжевать, нежели потом доделывать, доплачивать, дорабатывать. Последнее техническое задание, которое я писал, касалось разработки сайта. Это был большой информационный проект. Сначала разработали дизайн, а потом на его основе описывал функциональное задание для программистов. Так вот, все ТЗ получилось на 54 страницы А4 11 шрифтом. Техническое задание шло как дополнение к основному договору, который тоже был на 7 страниц. Но хочу сказать, что даже в таком детальном ТЗ не все смог учесть, ведь в процессе разработки подписывали еще три дополнительных соглашения, которыми я вносил определенные корректировки в первоначальный вариант задания.
  2. Техническое задание должно быть четкое. Не нужно никакой воды. Все по делу. Если пишите о срока, то конкретную цифру, если о функционале, то перечень нужных вам функциональных решений и т.д.
  3. Ваше техническое задание – это не догма, а лишь один из возможных вариантов исполнения задач. Скажу честно, я не специалист в программировании. Да, я могу продумать структуру проекта, его функционал, какие-то технические решения, но всегда, составляя окончательный вариант ТЗ, советуюсь с исполнителями. Они могут что-то увидеть, высказать свое мнение, подсказать оптимальное решение исполнение.

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

ПОДПИСАТЬСЯ НА НАШ КАНАЛ 

ПОДПИСАТЬСЯ НА НАШ VIULY КАНАЛ 

Тут дают 10 токенов VIU за подтвержденую регистрацию

Вступить в закрытый  Телеграм Чат

С уважением проект Анатомия Бизнеса

Рубрики:

Май 28, 2014 3:02 дп

Если Вам понравился опубликованный материал – поделитесь им с Вашими друзьями:

Источник: http://biz-anatomy.ru/vse-stati/poznavatelno/kak-pravilno-sostavit-texnicheskoe-zadanie-poshagovyj-algoritm

Стандарты и шаблоны для ТЗ на разработку ПО

Как составить техническое задание образец

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

Но не тут-то было! Одной статьи, где перечисляются стандарты для ТЗ, включая шаблоны и примеры готовых документов, я не нашел.

Придется сделать такую статейку самому… И так, основные стандарты, методологии и своды знаний, где упоминается ТЗ или 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.

Алфавитный указатель

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

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

ISO/IEC/ IEEE 29148-2011

Стандарт IEEE 29148-2011 обеспечивает единую трактовку процессов и продуктов, используемых при разработке требований на протяжении всего жизненного цикла систем и программного обеспечения. Он приходит на смену стандартов IEEE 830-1998, IEEE 1233-1998, IEEE 1362-1998.

Данный стандарт содержит два шаблона спецификации требований: • System requirements specification (SyRS) • Software requirements specification (SRS) System Requirements Specification (SyRS) определяет технические требования для выбранной системы и удобства взаимодействия предполагаемой системы и человека.

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

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

  • 1. Назначение системы
  • 2. системы (границы системы)
  • 3. Обзор системы
    • 1. системы
    • 2. Функции системы
    • 3. Характеристики пользователей
  • 4. Термины и определения

2. Ссылки 3. Системные требования

  • 1. Функциональные требования
  • 2. Требования к юзабилити
  • 3. Требования к производительности
  • 4. Интерфейс (взаимодействие) системы
  • 5. Операции системы
  • 6. Состояния системы
  • 7. Физические характеристики
  • 8. Условия окружения
  • 9. Требования к безопасности
  • 10. Управление информацией
  • 11. Политики и правила
  • 12. Требования к обслуживанию системы на протяжении ее жизненного цикла
  • 13. Требования к упаковке, погрузке-разгрузки, доставке и транспортировке

4. Тестирование и проверка (список необходимых приемочных тестов, которые отражают зеркально раздел 3) 5. Приложения

  • 1. Предположения и зависимости
  • 2. Аббревиатуры и сокращений

SRS это спецификация требований для определенного программного изделия, программы или набора программ (продукт), которые выполняют определенные функции в конкретном окружении. Из определения следует, что это аналог ТЗ, описанного в Гост 19, а по структуре очень напоминает SRS из стандарта IEEE 830. SRS может содержать следующие разделы: 1.

Введение

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

2. Ссылки 3. Детальные требования

  • 1. Требования к внешним интерфейсам
  • 2. Функции продукта
  • 3. Требования к юзабилити
  • 4. Требования к производительности
  • 5. Требования к логической структуре БД
  • 6. Ограничения проектирования
  • 7. Системные свойства ПО
  • 8. Дополнительные требования

4. Тестирование и проверка (список необходимых приемочных тестов, которые отражают зеркально раздел 3) 5. Приложения

  • 1. Предположения и зависимости
  • 2. Аббревиатуры и сокращений

Данный стандарт достаточно сложно найти в открытом виде в Интернете, но постараться можно, и опять же только на англ.

RUP

Структура SRS в RUP(Rational Unified Process) представляет собой документ, в котором необходимо описать артефакты, полученные в процессе специфицирования требований.

Шаблон SRS в RUP адаптирован из стандарта IEEE STD 830 и содержит два варианта:

• Традиционный шаблон SRS со структурированными функциональными требованиями по функциям Системы, максимально похож на 830 стандарт. • Упрощенный шаблон SRS со структурированными функциональными требованиями в виде вариантов использования (use cases): 1. Введение.

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

2. Обзор системы

  • 1. Обзор вариантов использований.
  • 2. Предположения и зависимости.

3. Детальные требований

  • 1. Описание вариантов использования.
  • 2. Дополнительные требования.
  • 3. Другие функциональные требования.
  • 4. Нефункциональные требования.

4. Вспомогательная информация.

Естественно, что в Интернете можно найти шаблон и примеры SRS от RUP.

SWEBOK, BABOK и пр

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

Также стоит сказать, что для описания требований к АС и ПО используются и другие виды документов, кот каждый называет по разному: FRD (Functional Requirements Document), RD (Requirements Document), ПЗ (Постановка задачи или Пояснительная записка) и пр.

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

А как же agile?

Я скажу одной фразой из Манифеста Agile: “Working software over comprehensive documentation”. Поэтому в Agile документации отводится совсем мало места. Мое же убеждение, что разработать АС без ТЗ можно (используя техники/рекомендации Agile), но вот в дальнейшем сопровождать — невозможно. Поэтому сразу задумайтесь, как вы будете писать ТЗ и другую документацию, при разработке ПО по Agile.

Заключение

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

Но главное, чтобы ТЗ не превращалось в ХЗ, а, именно, содержание (наполнение) в ТЗ — самое главное! Но это уже совсем другая история… Если есть интерес, то можно пройти он-лайн курс Разработка и управление требованиями к ПО.

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

Также рекомендую ознакомиться со следующими материалами:

Источник: https://habr.com/post/328822/

10 заповедей технического задания (с толкованием)

Как составить техническое задание образец

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

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

Форматы ТЗ перерабатывались, перерабатываются и будут перерабатываться. Формулировки переписываются, какие-то разделы вымарываются, новые добавляются. Толщина документа непостоянна, как ветер мая.

А потому, когда меня в один момент попросили прочитать доклад о техническом задании для сотрудников агентства, я растерялся. А про что читать? Рассказывать незаконченную историю становления технического задания? Разъяснить текущий формат, который к вечеру я захочу подправить?

Из этих вопросов и родились «10 заповедей о техническом задании». Я посмотрел на ТЗ не как на документ (артефакт), а как на часть процесса производства, и все стало ясно.

1. ТЗ — обязательный документ при создании любого продукта

Миф о том, что для простых проектов ТЗ не нужно, не выдерживает критики. Нужно! И для простого, и для сложного. Просто для простых проектов пишите простое ТЗ, а для сложных — сложное, если вы верите, что для ТЗ такая градация существует в принципе.

2. ТЗ описывает продукт, но не проект

ТЗ должно отвечать на вопрос «Что делаем?», но не «Как делаем?».

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

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

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

3. ТЗ не является договором

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

4. ТЗ описывает не только функциональные требования, но и интерфейс

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

5. ТЗ составляет только обладающий соответствующей компетенцией специалист

Звучит просто, а реализуется сложно.

Я не верю в клиентские ТЗ. Я не верю в ТЗ, которые пишут менеджеры. Кто же его пишет?

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

6. ТЗ разрабатывается после этапа дизайна, но до начала верстки

Подробно я об этом уже писал на Cossa. Коротко. Если делать ТЗ до дизайна, то устанете вносить изменения в этот документ, и потратите кучу сил/денег/времени/сотрудников/заказчиков. Поэтому мы в qb.

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

Тут же возникает резонный вопрос: «А по чему рисуется дизайн?». Отвечаем: по концептуальному описанию, функциональному описанию и прототипам.

7. ТЗ не терпит правок после его утверждения

Когда ТЗ утверждено, то считается, что производство запущено. Вносить правки в продукт во время его производства — кошмарный сон менеджера (как минимум). Единственным исключением здесь может быть ситуация, когда в документации нашли ошибку. А вот если поменялись требования к продукту (неважно по какой причине) — дополнение к ТЗ, дополнительные затраты и пр.

8. ТЗ может править только его автор или обладающий компетенцией специалист

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

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

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

9. ТЗ должно описывать, как минимум, текущую версию продукта

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

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

И когда возникнет вопрос «А как это работает?» (а он, поверьте, возникнет), то ответить на него не сможет никто.

10. ТЗ должно быть прочитано, понято и утверждено всеми заинтересованными лицами

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

Я видел много проектов, которые превращались в ад только потому, что кто-то или не читал ТЗ, или читал его невнимательно, или читал, но не понял.Добивайтесь чёткого понимания ТЗ у себя любыми силами.

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

Источник: https://www.cossa.ru/234/125799/

Как должно выглядеть техническое задание на разработку сайта – пример

Как составить техническое задание образец

О чём вы думаете, когда видите по городу или на сайтах (в рекламных блоках) баннеры с заголовками: «Сайт за 500 грн.», «Сайт за 1000 руб.»?

Я, как разработчик, долго думала — развод! Но количество подобных объявлений наводит на мысли:

  • А возможно ли такое вообще?
  • Какое качество будет у сайта в таком случае?
  • Можно ли будет его потом продвигать?
  • Займёт ли он достойные позиции?
  • Будет ли он удобным и будет ли возможность его редактировать?

Конечно, порой приемлем и простой набор HTML-файлов: если страниц немного, их редко меняют из-за тематики и владелец сайта (или контент-менеджер) знает HTML.

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

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

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

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

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

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

Тз по разработке сайта

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

Не стесняйтесь и не ленитесь приводить примеры сайтов, на которых вам нравится тот или иной функционал или элементы дизайна, вёрстка, эффекты. Но! не просто давайте ссылки, а прикрепляйте скриншоты.

Вы можете составить ТЗ, а владелец сайта (который вы приведёте в пример) к тому моменту, когда ТЗ перейдёт к исполнителю, поменяет вёрстку.

Тогда вам снова придётся искать пример и объяснять, что вы имели в виду.

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

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

Десктопная версия

Общая информация

Ширина сайта – 1140 px (пример –vizaua.com).Шапка и футер растягиваются по ширине экрана и одинаковы для всех страниц.Семейство шрифтов: Cambria (предпочтительно), Century, Georgia. Можно указать и другие популярные шрифты с засечками.Размеры шрифтов (для Cambria):Текст под логотипом в шапке – 15pxСсылки в шапке – 14px

Текст в футере – 16px

страница – home.png

Текст над строкой поиска – 25px

Текст под строкой поиска – 14px

Описание элементов:

1, 2 – цифры с реальным числом магазинов и отзывов. Можно пересчитывать один раз в 24 часа.3 – категории. Располагаем вручную в таком порядке, как на макете.4 – ссылки на магазины. Рядом с названием магазина выводим число отзывов. Если отзывов ещё нет, ничего не выводим.

Под каждой категорией выводим 6 самых популярных по количеству отзывов магазинов. Если в категории есть ещё магазины, на неё ведёт ссылка «Ещё N», где N – число магазинов. Если больше магазинов нет, на категорию ведёт ссылка «Показать всё».

5 – список низкопопулярных категорий.

Выводим их тут.

Страница с описанием магазина и отзывами – shop-page.png

Заголовок H1 – 30px
Заголовок H2 – 22px

Описание элементов:1, 2, 3 – место под рекламные блоки. Нужно отметить это место при вёрстке и закрыть к индексации.4 – контент страницы.

Дизайн меняется таким образом, чтобы все изменения можно было внести глобально, без редактирования каждой страницы по отдельности:– добавлен серый фон контентного блока;– добавлен белый border у таблиц (по умолчанию, вроде, нигде не прописывался);— добавлено место под рекламный блок над отзывами.

5 – заголовок формы. Нужно проставить «».

6 – последние отзывы (сквозной блок для постов и категорий). Это примерное отображение, допускается готовый плагин с похожей визуализацией.

Страница категории – category-archieve.png

Ссылки на магазины – 18 px, цвет # 336699
Текст в анонсах – 14px

Описание элементов:1,2 – место под рекламные блоки.3 – контентная часть. Нужно удалить все описания категорий (тексты сохранить в отдельном .doc-файле и загрузить этот файл на сервер).

4 – ссылка на отзывы. Во всех шаблонах ТЗ слово «комментарии» меняем на «отзывы».

Служебная страница – page.png

Размер шрифта – 15pxРекламные блоки не выводим.

В меню справа выводим только поиск и ссылки на категории. Отзывы не выводим.

404 ошибка – 404.png

404 – шрифт 80pxТекст под ним – 20px

Наклонный текст – 15px

Ссылки навигации:– на главную – 16px

– на служебные страницы– 14px

Активные элементы:Все ссылки подчёркнутые, убираем подчёркивание при наведении, цвет ссылки на несколько оттенков темнее (на усмотрение исполнителя).

Цвет кнопки #ddd, при наведении появляется курсор в виде руки.

Рекомендую делать отдельные макеты и описывать поведение всех ссылок, кнопок, выпадающих меню, всплывающих окон.

Мобильная вёрстка

Сейчас лучше ставить мобильную вёрстку главной и от неё «плясать». Не зря же вся справка и блог Google пестрят «Mobile first» (сначала мобильные или мобильность). Мы говорим вам об этом с 2014 года (статьи «3 способа быстро адаптировать сайт под мобильные устройства» и «Мобильная адаптация сайта — ответы на вопросы» ).

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

  • Контактам. Номера телефонов должны быть кликабельными – при нажатии должна открываться панель ввода номера с уже набранным номером и кнопкой вызова.
  • Меню. Опишите, как оно должно открываться: выезжать сбоку, сверху и т. д.
  • Не должно быть горизонтальной прокрутки на страницах сайта (это само собой разумеется, но я всё же решила напомнить).

Ниже представлены макеты страниц для отображения сайта на мобильных устройствах (адаптивная вёрстка).

Основные требования:
– меню-бургер – раскрывается вниз при касании значка меню:

– сайдбар опускаем под основной контент:

– все элементы в футере находятся друг под другом:

страница

Все элементы выводятся друг под другом:

  • краткое описание;
  • форма поиска;
  • подробное описание;
  • списки магазинов, разделённые по категориям.

На этом примере, кстати, действительно всё предельно ясно, можно обойтись без описания.

Страница категории

Страница магазина

Все элементы выводим друг под другом, в том числе колонки в таблице.

Информационная страница

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

P.S.

Еще по теме:

Есть вопросы?

Задайте их прямо сейчас, и мы ответим в течение 8 рабочих часов.

Источник: https://siteclinic.ru/blog/technical-aspects/tz-na-razrabotku-sajta-primer/

Дом права
Добавить комментарий