ТЗ техническое задание

9.1. Основные этапы при построении системы защиты персональных данных

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

1. предпроектная стадия или оценка обстановки;
2. стадия проектирования;
3. ввод в действие СЗПД.

Предпроектная стадия или оценка обстановки. В самом начале построения СЗПД производится оценка обстановки. На данном этапе производятся следующие работы:

1. разрабатывается перечень информационных систем организации, которые работают с ПД;
2. определение состава ПД и необходимость их обработки;
3. определение перечня ПД, которые необходимо защищать;
4. определение контролируемой зоны и расположения компонентов ИСПД относительно границ этой зоны;
5. строится модель корпоративной сети;
6. определение топологии и конфигурации ИСПД, программ и технических средств, которые используются или предполагаются к использованию для обработки ПД;
7. установление связей ИСПД с другими системами организации;
8. определение режимов обработки ПД;
9. определение угроз безопасности;
10. определение класса ИСПД;
11. уточняется степень участия персонала в обработке ПД.

Важным пунктом данного этапа является построение частной модели угроз и предварительная классификация ИСПД данной организации. Классификация ИСПД производится в соответствии с приказом » Об утверждении Порядка проведения классификации информационных систем персональных данных» от 13 февраля 2008 года. Результатом данного этапа является формирование частного технического задания (ТЗ) к СЗПД .

Техническое задание должно содержать:

• обоснование разработки СЗПД;
• исходные данные создаваемой (модернизируемой) ИСПД в техническом, программном, информационном и организационном аспектах;
• класс ИСПД;
• ссылку на нормативные документы, с учетом которых будет разрабатываться СЗПД и приниматься в эксплуатацию ИСПД;
• конкретизацию мероприятий и требований к СЗПД;
• перечень предполагаемых к использованию сертифицированных средств защиты информации;
• обоснование проведения разработок собственных средств защиты информации при невозможности или нецелесообразности использования имеющихся на рынке сертифицированных средств защиты информации;
• состав, содержание и сроки проведения работ по этапам разработки и внедрения СЗПД.

1. стадия проектирования. На данном этапе разрабатывается задание и проект проведения работ в соответствии с ТЗ, выполняются все требуемые работы, в том числе закупка технических средств защиты и их сертификация в случае необходимости. Разрабатывается система доступа к ПД должностных лиц и определяются ответственные за эксплуатацию средств защиты информации.

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

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

2. ввод в действие СЗПД. Данный этап включает в себя:
   • генерация пакета прикладных программ в комплексе с программными средствами защиты информации;
   • опытная эксплуатация средств защиты информации в комплексе с другими техническими и программными средствами;
   • приемо-сдаточные испытания;
   • организация охраны и физической защиты помещений ИСПД;
   • оценка соответствия ИСПД требованиям безопасности ПД.

В случае если в процессе опытной эксплуатации выявляются недостатки разработанной СЗПД, проводится ее доработка.

Для ИСПД, находящихся в эксплуатации до введения ФЗ №152 «О персональных данных» от 27 июля 2006 года, должны быть проведены работы по их модернизации в соответствии с требованиями Федерального закона и «Положения об обеспечении безопасности персональных данных при их обработке в информационных системах персональных данных» №781.

9.2. Комплекс организационных и технических мероприятий в рамках СЗПД

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

Организационные меры носят административный и процедурный характер и регламентируют процессы функционирования ИСПД, обработку ПД и действия персонала. Организационные меры включают в себя:

1. разработка организационно-распорядительных документов, предназначенных для регламентации процессов хранения, обработки, сбора и накопления персональных данных, а также их защиту;
2. уведомление уполномоченного органа (Роскомнадзора) о намерении обрабатывать ПД;
3. получение письменного согласия на обработку ПД от субъектов ПД;
4. определение должностных лиц, которые будут работать с ПД;
5. организация доступа в помещения, где будет вестись обработка ПД;
6. разработка должностных инструкций по работе с ПД;
7. определение сроков хранения ПД;
8. планирование мероприятий по защите ПД;
9. обучение персонала.

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

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

1. для выполнения работ по технической защите требуется лицензия;
2. для выбора адекватных и достаточных средств защиты необходимо тщательное обследование ИСПД, построение модели угроз и классификация ИСПД;
3. на основе данного обследования формируется перечень требований по обеспечению безопасности;
4. требуется провести работы по проектированию, созданию и вводу в эксплуатацию СЗПД;
5. для проведения аттестации(сертификации) на соответствие ИСПД требованиям законодательства необходимо наличие соответствующих лицензий.

Согласно Указу Президента РФ «Об утверждении перечня сведений конфиденциального характера» персональные данные относятся к категории сведений конфиденциального характера. На основании Федерального закона от 8 августа 2001 г. №128-ФЗ «О лицензировании отдельных видов деятельности» техническая защита конфиденциальной информации (в нашем случае персональных данных) относится к лицензированному виду деятельности. Таким образом, для проведения мероприятий по защите персональных данных необходимо привлекать организации, имеющие соответствующие лицензии ФСТЭК. Деятельность по защите информации без наличия соответствующих лицензий влечет за собой как административную, так и уголовную ответственность.

Помимо вышеперечисленного, средства технической защиты согласно п.6 Положения №781 » «Об обеспечении безопасности персональных данных при их обработке в информационных системах персональных данных» должны проходить процедуру соответствия. Другими словами, можно применять только те средства защиты, которые имеют сертификат соответствия ФСТЭК или ФСБ в зависимости от назначения средства.

9.3. Уведомление Роскомнадзора об обработке персональных данных

До начала обработки персональных данных оператор обязан уведомить Роскомнадзор о своем намерении в соответствии с ФЗ «О персональных данных».Уведомление должно быть в письменной форме с подписью уполномоченного лица или в электронной форме с ЭЦП. Уведомление должно содержать:

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

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

В поле категории персональных данных перечисляются все категории обрабатываемых ПД (основные, специальные, биометрические).

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

В поле правовое основание обработки персональных данных необходимо указать не только соответствующие статьи из ФЗ «О персональных данных», но и статьи из других правовых документов, регламентирующих обработку ПД в данном случае. Например, при обработке ПД сотрудников — ст. 85-90 Трудового кодекса Российской Федерации.

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

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

• неавтоматизированная обработка персональных данных;
• исключительно автоматизированная обработка персональных данных с передачей полученной информации по сети или без таковой;
• смешанная обработка персональных данных.

При этом, если обработка автоматизированная или смешанная, необходимо указать, передается информация только по локальной сети или с использованием Интернета.

В поле описание мер описываются меры, предусмотренные статьями 18 и 19 ФЗ «О персональных данных», в том числе сведения о шифровальных средствах, ФИО и контакты лиц, ответственных за обработку ПД, класс ИСПД, организационные и технические меры, применяемые оператором в целях защиты ПД.

В поле срок или условие прекращения обработки ПД указывается конкретная дата или условие, при выполнении которого обработка будет прекращена.

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

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

Что такое техническое задание

Образец технического задания по 44-ФЗ является частью закупочной документации и неотъемлемым приложением к проекту госконтракта. На основании техзадания заказчики выявляют основные параметры госзакупки. В положениях ТЗ подробно описывается объект закупки, условия поставки, ключевые требования как к приобретаемой продукции, так и к самим исполнителям. Образец формы технического задания по 44-ФЗ представляет собой подробное руководство для потенциальных поставщиков, в котором детально описаны все аспекты тендера. Приобретение товаров, работ, услуг для нужд заказчиков — процесс многоэтапный. Перед непосредственным объявлением госзакупки и публикацией извещения организация-заказчик прорабатывает документы, которые будут характеризовать данный тендер: определять предмет госконтракта, цену, объем, условия, требования и специфику закупаемого объекта. Далее подробно рассмотрим, как составить техническое задание по 44-ФЗ специалисту заказчика. Различные объекты госзакупки подразумевают особые условия и требования. Поэтому невозможно привести один универсальный пример технического задания по 44-ФЗ, образец техдокументации зависит от типа закупаемого товара, работы или услуги. Вот несколько примеров.

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

Скачать техзадание на поставку электрооборудования

Скачать техзадание на ремонтные работы

Скачать техзадание на поставку продуктов питания

Скачать техзадание на услуги по техподдержке пользователей

Чем отличается техзадание от описания объекта заказа

Техзадание входит в состав закупочной документации, а описание объекта госзакупки, в свою очередь, является его обязательной частью. Но какие-либо требования к техническому заданию по 44-ФЗ не установлены, а вот описание предмета торгов регламентируется законодательными нормативами, закрепленными в законе о Федеральной контрактной системе (ст. 33 44-ФЗ). Разработкой ТЗ надлежит заниматься всем специалистам, участвующим в процессе госзаказа в учреждении: начиная от контрактного управляющего или специальной службы и заканчивая юридическими и техническими специалистами. Связано это с тем, что ТЗ представляет собой инструкцию для поставщика, включающую различные разделы. И если заказчик хочет, чтобы результаты торгов были максимально эффективными и победил именно тот поставщик, который предложит наиболее оптимальный для организации вариант, то к составлению технической документации следует привлечь сотрудников, которые специализируются на каждом отдельном разделе ТЗ. Формирование технической формы базируется и на государственных стандартах (ГОСТ) составления и ведения программной документации. Заказчик не обязан использовать образец технического задания по ГОСТу. Это вспомогательная мера, которая упрощает разработку корректных закупочных документов. Межгосударственные стандарты могут использоваться в зависимости от отраслевой принадлежности организации-заказчика или специфичности приобретаемых товаров, работ или услуг.

Требования к техзданию

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

• ГОСТ Р 7.0.97-2016, включающий требования к оформлению различной документации;
• реестр госзакупок в Единой информационной системе;
• иные источники общедоступных данных.

В техническом задании должны быть прописаны наименование объекта госзаказа, а также основные требования и условия к нему. Название предмета заказа приводится на основании действующего каталога товаров, работ, услуг (КТРУ) (утв. ПП РФ № 145 от 06.02.2017). Изучив искомую позицию в КТРУ, специалист заказчика описывает объект госзаказа в строгом соответствии с конкретной строкой каталога. В случае несовпадения прописанных в КТРУ характеристик и описания заказчика ответственный специалист приводит письменное обоснование, указывая при этом требуемое наименование закупаемого объекта (Правила, закрепленные Постановлением Правительства № 555 от 05.06.2015). В техническом задании описывается конечный результат закупки в части товаров, работ и услуг, учитывающий все потребности заказчика. Формирование описательной части нормируется статьей 33 44-ФЗ. Эти правила нужно также учесть и при разработке всего техзадания:

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

Как составить техническое задание: пошаговая инструкция

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

1. В первую очередь нужно детерминировать параметры закупки — установить и расшифровать терминологию, которая будет применяться в техническом задании.
2. Составить информационную карту. В этом разделе приводятся общие сведения о заказе — полное или краткое название организации-заказчика, его регистрационные и контактные сведения, организационно-правовая форма, местонахождение, ответственное лицо и его контакты.
3. Внести информацию о самой госзакупке — объект торгов и его обоснование (ст. 33), объем и срок поставки, способ определения поставщика, подрядчика или исполнителя (ч. 1 ст. 24 44-ФЗ), обоснование данного способа. Также нужно указать, является ли данная закупка совместной или нет (ПП РФ № 1088 от 28.11.2013), централизованной, ведет ли заказ уполномоченный орган (ч. 1 ст. 26 44-ФЗ), привлекаются ли экспертные организации или иные специалисты.
4. Прописать все требования к потенциальным поставщикам, участвующим в торгах.
5. Указать особые характеристики, которыми должен обладать исполнитель, — определенные производственные мощности или опыт в исполнении аналогичных контрактов.
6. Отразить специфические условия по заказу, непосредственно связанные с его исполнением, возможные экологические условия (режим работы, производственные требования, особенности, которые могут возникнуть при транспортировке, установке или вводе в эксплуатацию приобретаемой продукции).
7. Отразить основные цели и задачи объявляемой закупки (ст. 13 44-ФЗ).
8. Прописать в задании источник финансирования госзаказа.
9. Определить обязанность поставщика следовать действующему законодательству и нормативно-правовым актам в ходе исполнения госзакупки, отразить нормирование заказа в соответствии с ч. 1 ст. 19 44-ФЗ.
10. Описать порядок поставки (как будет производиться транспортировка, какая будет упаковка и т. д.), сдачи, приемки, установки, необходимость монтажа или демонтажа, ввод в эксплуатацию. Внести требования о гарантии и гарантийном сроке.
11. Подтвердить обязательство о поставке новой продукции (не употреблявшейся ранее) или указать необходимость приобретения иных товаров для нужд заказчика.

Готовый документ может выглядеть так:

Разъяснения по теме

Основные тезисы	Реквизиты документа	Документ
Требование указать в заявке параметры не только самого товара, но и компонентов, которые применяются при его изготовлении (например, химические показатели составных частей, результаты испытаний), считается избыточным.	Письмо от 31.05.2016 № РП/36546/16
Отдельные вопросы подготовки технического задания для закупки лекарств по Постановлению Правительства № 1380 от 15.11.2017.	Письмо Минздрава № 418/25-5 от 14.02.2018
	Письмо ФАС № АК/12985/18 27.02.2018	Скачать
Объединение в техническом задании лицензируемых и нелицензируемых видов работ может ограничивать число участников закупки.	Письмо ФАС № АЦ/5147/15 от 09.02.2015
Требовать указать остаточный срок годности лекарств и медизделий в процентах неправомерно, если это приводит к ограничению конкуренции.	Письмо от № ИА/71717/17 от 18.10.2017
Закупать запчасти без работ, для выполнения которых они нужны, нельзя.	Письмо Минфина № 24-02-07/73170 от 07.11.2017

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

Проблема

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

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

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

1) ТехЗадание — оно ставит задачу. А значит оно должно идти перед прототипом, скетчем, тестом, дизайн-проектом, потому что любой майндмеп, диаграмма потоков данных, архитектура — это уже выполнение некой задачи, это ответ на вопрос. А до того, как сам вопрос еще не задан, не сформулирован и не подписан всеми сторонами — любой ответ будет априори неправильным, не так ли? Итак, начало любой работы над любым проектом — это постановка задачи, а не судорожный поиск набросков десятка вариантов ее решения.
2) Собственно из первого пункта логично вытекает и новый — сам текст ТЗ обязан начинаться с главы «Цели и задачи», четко формулирующей, какие бизнес-цели преследует вся эта очередная попытка повысить энтропию в мире. Бесцельное задание, которое не решает никаких проблем, не достигает ничего и делается «от скуки» — официально не считается Техническим Заданием, а с этого момента находится в статусе «обычная бумажка».
3) Как же вам понять, решает ли предложенная дизайн-концепция или интерактивный прототип, а то и готовый к употреблению сайт — вышеизложенную задачу бизнеса? Ничего не поделаешь, придется опять вернуться к определению: «определяет… ожидаемые результаты и сроки выполнения. То есть должны быть объективные критерии, по которым можно определить, сделан ли тот или иной пункт работ или нет». То есть ТЗ без четких измеримых показателей в рублях, секундах, тонно-километрах или градусах Цельсия — быть не может. Бриф может, или прототип, или еще любая абсурдная бумажка, но только не ТехЗадание.
Отсюда делаем вывод, что в настоящем ТЗ обязательно должна быть глава «Порядок приемки и оценки», когда эти самые показатели берутся, замеряются, и стороны либо пожимают друг другу руки, либо отправляют проект на переделку.
4) ТехЗадание должно обязательно согласоваться с общим бизнес-планом заказчика, с его стратегией развития бизнеса и анализом сегмента рынка. Именно все это позволит установить правильные цели, вывести точные метрики, по которым затем адекватно провести приемку готового инфопродукта. Отсутствие у заказчика бизнес-плана автоматически гарантирует непрофессиональное выполнение Технического Задания.
Знает ли студия на аутсорсе бизнес-цели и измеримые показатели бизнеса лучше его владельца? Очевидно, что нет, а значит правильное ТЗ должно писаться представителями Заказчика, а не наемными работниками Исполнителя. Абсурд, когда исполнитель сам себе ставит задачу, затем сам себе придумывает способы ее оценки, и в конце сам же выставляет себе итоговую отметку за сделанную работу. В идеале такой «самодеятельности» быть не должно, хотя на практике повсюду именно так и происходит, в результате чего ТехЗадание и не оказывает нужной помощи проекту, слишком часто являясь по сути фиктивным документом. Не надо так.
5) Каждое внесение правок в готовое ТЗ должно стоить денег. Нельзя бесплатно и бесконечно править «Конституцию вашего проекта» только потому, что одна из сторон передумала, не выспалась, внезапно решила сэкономить и т.д. Цена каждого изменения в ТЗ должна также четко прописываться заранее в соответствующей главе.
Кстати, по идее точно также каждая правка в дизайне или внесение изменений в список страниц или функций должна иметь четкую цену, которая оплачивается заранее, до начала внесения данного изменения. Лично я предлагаю любую редактуру утвержденного ТЗ оценивать в 30% от всего бюджета проекта, но вы можете поступать иначе.
Стоит ли упоминать, что в ТЗ просто необходимо заранее указывать сроки и общий бюджет на разработку, а также список всех существующих ресурсов и ограничений? — Нет, это будет уж слишком очевидно.
Итак: Что делаем? Для чего? Как поймем, что сделали? Сколько стоит каждый пивот? — написанные на листочке ответы на все эти вопросы и являются «серебряной пулей», способной вытащить даже самый провальный проект.

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

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

1) Так что, на написание ТехЗадания может еще и официальный ГОСТ есть? — Да, даже несколько.
2) А что, в ТехЗадание не входит описание нужных страниц, количества кнопок, используемых библиотек, гайдлайнов и т.д.? — В само ТЗ нет, но в Приложения вы можете все это поместить, разумеется скорректировав все это с вышеописанными целями, ограничениями и способами дальнейшей оценки достигнутого результата. Размещайте хоть весь будущий контент, хоть описание типовых персонажей — но не вместо четкой постановки задачи, а уже после нее.
3) Так может оно мне такое и не нужно? — Возможно, сегодня тысячи сайтов делаются вообще без ТЗ, также, как тысячи людей в мире прекрасно живут, будучи слепыми от рождения. Но если вы хотите видеть — куда вы вообще движетесь, осознанно принимать решения и самостоятельно оценивать полученные результаты — то без ТЗ тут не обойтись.
4) Вот вы и Википедия пишете, что ТЗ создается заказчиком. Но я не умею\мне некогда\просто не хочу его делать сам. Как же быть? — Отдать разработку ТЗ третьей стороне, вполне знакомой с вашим бизнесом, его задачами, целевой аудиторией и потребностями, и в то же время досконально осведомленной о всех этапах веб-разработки. Эта третья сторона станет неким «веб-нотариусом», то есть гарантом того, что исполнитель не занизит нужные вам показатели или не затянет сроки, и что заказчик установит достижимые метрики и на итоговой приемке не будет субъективно оценивать созданный продукт, на ходу изменяя зафиксированные ранее требования.
5) И что, если ТЗ является юридическим документом, то я потом могу засудить аутсорсера, не заплатить ему, заставить переделать все в десятый раз? — Если документ составлен правильно, указаны цели и методология оценки их достижения; если документ подписан сторонами и упомянут в Договоре (само ТехЗадание договором не является) — то конечно же сможете. А вот с обычным брифом, прототипами, арт-креатив-макетом, Безопасной сделкой на FL — уже нет.
6) Мне говорят, что работа будет вестись по какому то то ли скраму, то ли аджайлу; а значит архаичное ТЗ мне больше уже не нужно. Это так? — Посудите сами: вам называют непонятное слово, явно что-то маскирующее и вот уже на основании незнакомого вам термина предлагают отказаться от юридически грамотного и наполненного целями и метриками документа. Сам же agile никаких целей вроде «достичь не менее 10 000 посещений к концу года», или «достичь цифры более 25 заказов с сайта через месяц» — установить не может, это просто способ проведения совещаний и новой организации нерадивых сотрудников. Задумайтесь несколько раз: «А не пускают ли вам пыль в глаза?». На самом деле никакому новомодному скраму профессиональное ТЗ повредить не может, а вот помочь — обязательно.

Введение

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

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).
Также рекомендую ознакомиться со следующими материалами:

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

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

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

Обозначим далее минимально необходимые ТТ на систему (изделие):

• Краткое описание назначения и области применения (желательны ссылки на существующее аналогичное оборудование).
• Требования к основным функциям.
• Требования к электрическим и параметрам (количественные требования обязательны!).
• Требование к конфигурации (количество каналов, количество модулей блоков и пр.)
• Требования к конструкции.
• Требование к ПО.
• Условия эксплуатации.
• Предполагаемая серийность изделия или описание потребности.

При составлении ТТ Вам может помочь раздел Терминология на этом сайте.

С данной темой связаны следующие статьи:

• ТЗ как неформальная основа взаимодействия Заказчик – Исполнитель при разработке
• Типичные организационные вопросы заказа на разработку
• Системная интеграция — инженерная задача
• Элементы конструкции и функциональное деление в системах сбора данных