Техническая спецификация — это документ, который фиксирует измеримые технические требования к продукции, процессу, услуге или системе так, чтобы исполнитель, заказчик и контролёр понимали их одинаково. В законодательстве Украины эта формулировка закреплена, в частности, в Законе «О технических регламентах и оценке соответствия»: спецификация устанавливает требования, которым должна удовлетворять продукция, процесс или услуга. В публичных закупках тот же термин означает совокупность технических условий к предмету закупки — от функционала и безопасности до упаковки, испытаний и воздействия на окружающую среду.
На практике документ работает как общая система координат. Он не заменяет стандарт и не является рекламным описанием изделия: он отвечает на вопрос, каким именно параметрам должен соответствовать результат и как это проверить. От качества спецификации зависит, получит ли заказчик нужное изделие, сможет ли подрядчик корректно оценить объём работ и выдержит ли проект проверку соответствия.
Ниже разобраны юридические и инженерные значения термина, отличия от технического задания, технических условий и стандарта, типовая структура документа, критерии качественных требований и типичные ошибки, которые срывают тендеры и разработку.
Что означает техническая спецификация в праве и инженерии
В украинском праве термин существует в нескольких слоях. Базовое определение даёт Закон Украины от 15 января 2015 года № 124-VIII: техническая спецификация — документ, устанавливающий технические требования, которым должна удовлетворять продукция, процесс или услуга. Эта формулировка согласована с европейской терминологией технического регулирования и повторяется в технических регламентах Кабинета Министров.
Отдельное, более узкое значение закреплено в Законе Украины «О публичных закупках» № 922-VIII. Техническая спецификация к предмету закупки — установленная заказчиком совокупность технических условий, определяющих характеристики товара, услуги или работ относительно объекта строительства. В эти условия могут входить показатели воздействия на окружающую среду и климат, требования доступности, производительности, ресурсоэффективности, безопасности, методики испытаний, упаковки, маркировки, инструкции пользователя и технологии на этапах жизненного цикла. Источник нормативных формулировок — портал законодательства zakon.rada.gov.ua.
В оборонных закупках спецификация — документ, утверждённый государственным заказчиком, с требованиями к качеству, техническим характеристикам, безопасности, размерам, терминологии, упаковке, маркировке и процедурам оценки соответствия. Здесь точность формулировок напрямую влияет на пригодность образца к эксплуатации.
В международной стандартизации слово имеет ещё два разных смысла, и их не стоит смешивать. Первый — общий: согласно классическому словарю ISO/IEC Guide 2, техническая спецификация излагает характеристики изделия или услуги (качество, безопасность, размеры, методы испытаний, маркировка) и может существовать как отдельный документ или как часть стандарта. Второй — статусный: Technical Specification (TS) в системе ISO/IEC — это отдельный вид публикации, который издают, когда международный стандарт ещё невозможен из-за недостатка консенсуса или незавершённости темы, но документ уже нужен рынку. Содержание TS может содержать требования; впоследствии его часто преобразуют в International Standard. Официальные разъяснения типов документов ISO приведены на iso.org.
В инженерии программного обеспечения и систем под «технической спецификацией» часто подразумевают детальное описание того, как система должна быть построена и какие ограничения она должна выдержать: архитектура, интерфейсы, данные, производительность, безопасность, среда развёртывания. Это уже не тендерное условие и не ISO TS, а рабочий артефакт команды. Стандарт ISO/IEC/IEEE 29148:2018 (в Украине принят как ДСТУ ISO/IEC/IEEE 29148:2025) описывает родственные информационные продукты: спецификацию требований заинтересованных сторон (StRS), системных требований (SyRS) и программных требований (SRS).
По моему опыту сопровождения тендеров и технических проектов в течение нескольких лет, большинство конфликтов «мы имели в виду другое» начинается не с плохого подрядчика, а с неоднозначного предложения в спецификации, которое каждая сторона читает в свою пользу.
Чем спецификация отличается от смежных документов
На бытовом уровне термины «техническое задание», «технические условия», «спецификация», «стандарт» и «технический регламент» смешивают постоянно. Разница принципиальна, потому что каждый документ отвечает на другой вопрос и имеет другую юридическую силу.
Техническое задание фиксирует цель, границы проекта, ожидаемый результат, ограничения, этапы и критерии приёмки. Оно ближе к договору между заказчиком и исполнителем: зачем делаем и что должно получиться. Техническая спецификация детализирует измеримые характеристики этого результата. В закупках спецификация часто входит в тендерную документацию как отдельное приложение; в разработке ПО её иногда пишут после утверждённого ТЗ как следующий уровень детализации.
Технические условия (ТУ) по Закону Украины «О стандартизации» — нормативный документ предприятия, устанавливающий требования к конкретной продукции, процессу или услуге и определяющий процедуры проверки этих требований. ТУ разрабатывает производитель или заказчик продукции. Спецификация может ссылаться на ТУ, но сама по себе не является ТУ. Национальный стандарт (ДСТУ) принимает национальный орган стандартизации; он рассчитан на многократное применение и доступен широкому кругу пользователей. Технический регламент — нормативно-правовой акт с обязательными характеристиками продукции; его несоблюдение имеет административные последствия, в отличие от большинства добровольных стандартов.
Конструкторская спецификация по правилам ЕСКД/ДСТУ на конструкторскую документацию — табличный документ состава сборочной единицы: обозначение, наименование, количество, материал. Это другой жанр: перечень комплектации, а не каталог требований к качеству. Издательская спецификация описывает условия набора, вёрстки и печати. В строительстве спецификации изделий составляют по профильным ДСТУ на проектную документацию.
| Документ | Главный вопрос | Кто утверждает | Типичное применение |
|---|---|---|---|
| Техническая спецификация | Каким измеримым требованиям должен соответствовать предмет | Заказчик, разработчик или орган закупки | Тендеры, контракты, инженерные проекты |
| Техническое задание | Зачем, что именно и в каких пределах создаём | Заказчик вместе с исполнителем | Разработка изделий, ИТ, проектирование |
| Технические условия | Какие требования к конкретной марке продукции и как их проверить | Предприятие-производитель | Серийный выпуск, кодификация |
| ДСТУ / ISO-стандарт | Какие согласованные правила действуют для класса объектов | Орган стандартизации | Унификация, оценка соответствия |
| Технический регламент | Какие требования обязательны по закону | Кабинет Министров / закон | Безопасность продукции на рынке |
Сравнение обобщает нормы законов «О стандартизации», «О технических регламентах и оценке соответствия» и «О публичных закупках» (законодательный портал Украины).
Где применяют документ и зачем он нужен
В публичных закупках спецификация — сердце тендерной документации. Статья 23 Закона № 922 требует описания всех необходимых технических, функциональных и качественных характеристик. Если исчерпывающее описание невозможно, разрешена ссылка на стандарты, регламенты, условные обозначения и терминологию — с приоритетом международных и европейских норм. Требования должны быть недискриминационными: нельзя прописывать конкретную торговую марку без слов «или эквивалент», если это искусственно сужает конкуренцию.
На производстве спецификация задаёт допуски, материалы, режимы обработки, методы контроля и критерии приёмки партии. Без этого цех работает «на глаз», а рекламации превращаются в спор о вкусе. В машиностроении и электротехнике документ часто существует рядом с чертежами: чертёж показывает геометрию, спецификация — остальные требования, которые на листе не уместить.
В разработке программного обеспечения техническая спецификация сводит бизнес-потребность к реализованному поведению системы. Функциональные требования описывают, что система делает с входными данными. Нефункциональные — насколько быстро, безопасно, доступно и устойчиво. Отдельно фиксируют ограничения стека, интеграции, лицензии, среду эксплуатации. В нашей практике мы сталкивались со случаем, когда отсутствие лимита размера файла и времени отклика API на этапе спецификации стоило команде двух спринтов переделок после нагрузочных испытаний.
Строительство использует спецификации материалов, оборудования и работ как приложение к проектной документации: марка бетона, класс арматуры, теплотехнические показатели ограждающих конструкций, требования к узлам и испытаниям. Медицинские изделия, средства измерений, радиооборудование подпадают под технические регламенты, поэтому спецификация закупки или разработки должна воспроизводить обязательные характеристики регламента, а не противоречить им.
Из чего состоит качественная техническая спецификация
Универсального бланка на все отрасли нет, но рабочий каркас повторяется. Документ начинается с идентификации: название предмета, код по классификатору (для закупок — ДК 021:2015), версия, дата, автор и статус утверждения. Далее идёт сфера применения и определения терминов, чтобы «производительность», «партия» или «отказ» не читались по-разному.
Основной блок — требования. Их группируют по природе: функциональные, эксплуатационные, эргономические, экологические, требования безопасности, совместимости, упаковки, маркировки, транспортировки и хранения. Каждое требование должно иметь идентификатор, формулировку, единицу измерения, предельное значение или допустимый диапазон и метод проверки. Метод проверки — не украшение. Предложение «должен быть надёжным» без критерия отказа и методики испытания невозможно ни принять, ни отклонить.
Отдельно описывают комплект поставки, сопроводительную документацию, гарантии, сервис и условия ввода в эксплуатацию. Для ИТ добавляют модели данных, контракты API, матрицу прав доступа, сценарии отказов, политику журналирования и критерии отката релиза. Для работ — технологическую последовательность, допуски, требования к квалификации персонала и охране труда.
Закрывают документ перечнем нормативных ссылок, приложений (чертежи, схемы, фото эталона, протоколы типовых испытаний) и журналом изменений. Журнал изменений критичен, когда спецификацию уточняют после вопросов участников тендера или после прототипа.
- Идентификация и статус. Номер версии, дата, кто утвердил, на какой предмет распространяется документ и что исключено из сферы.
- Термины, обозначения, нормативные ссылки. Краткий глоссарий и перечень стандартов именно тех редакций, которые действуют на дату документа.
- Функциональные и качественные требования. Что объект делает, с какой точностью, в какой среде, с какими интерфейсами.
- Ограничения и совместимость. Питание, климат, электромагнитная совместимость, протоколы обмена, требования доступности.
- Контроль и приёмка. Методы испытаний, объём выборки, критерии соответствия, кто и где проводит проверку.
- Поставка, упаковка, сопровождение. Комплектность, маркировка, инструкции, гарантийный срок, условия сервиса.
Этот каркас можно сокращать для простой закупки канцелярии и расширять до сотен страниц для сложной системы. Важнее не объём, а однозначность каждого пункта.
Как формулировать требования, чтобы их можно было проверить
ISO/IEC/IEEE 29148 описывает свойства отдельного требования и набора требований. Отдельное требование должно быть необходимым, однозначным, полным, согласованным с другими, осуществимым, проверяемым и прослеживаемым до источника потребности. Набор требований — полным, согласованным, осуществимым в пределах бюджета и сроков и свободным от внутренних противоречий.
Практическое правило языка: подлежащее — система или изделие, сказуемое — «должен» плюс измеримая характеристика. «Система должна сохранять файл объёмом до 10 МБ и возвращать код завершения не позднее чем за 2 с при нагрузке 100 одновременных запросов» — это требование. «Система должна работать быстро и удобно» — пожелание. Субъективные слова «современный», «качественный», «эргономичный», «на уровне лучших аналогов» нужно либо удалять, либо раскрывать через конкретные показатели.
Для закупок стоит отдавать предпочтение функциональным и эксплуатационным требованиям над описанием конкретного технологического процесса, если процесс сам по себе не является предметом закупки. Так сохраняется конкуренция: участник может предложить другой способ достичь того же результата. Если нужен конкретный стандарт, указывают его обозначение и год, добавляют допуск эквивалента с подтверждением соответствия.
Прослеживаемость спасает на приёмке. Каждое требование должно иметь источник: норма регламента, пункт договора, протокол обследования объекта, пользовательский сценарий. Тогда изменение в одном месте не «теряется» в тексте на двадцатой странице.
| Слабая формулировка | Почему не работает | Проверяемая замена |
|---|---|---|
| Высокое качество изображения | Нет метрики | Разрешение не менее 1920×1080, цвет 24 бита |
| Надёжный корпус | Нет метода проверки | Степень защиты IP65 по соответствующему ДСТУ / IEC |
| Совместим с имеющейся сетью | Сеть не описана | Интерфейс Gigabit Ethernet, IEEE 802.3, RJ-45 |
| Удобный интерфейс | Оценка вкусовая | Ключевое действие выполняется не более чем за 3 клика; соответствие ДСТУ EN 301 549 для доступности |
Примеры иллюстрируют принцип проверяемости из инженерной практики составления требований; конкретные числовые пороги всегда берут из потребности заказчика и действующих стандартов на изделие.
Типичные ошибки и как их избежать
Первая группа ошибок — юридическая. Заказчик копирует спецификацию прошлогоднего тендера, не проверив действительность ДСТУ и ТУ. Ссылка на отменённый стандарт даёт участникам основания оспаривать документацию. Вторая — дискриминация: указана конкретная модель без эквивалента, «уникальные» параметры, которые есть только у одного производителя, лишние сертификаты, не предусмотренные законодательством для этого изделия.
Третья группа — техническая неполнота. Нет условий эксплуатации (температура, влажность, запылённость), нет критериев приёмки, нет требований к запасным частям. Четвёртая — внутренние противоречия: в тексте «напряжение 220 В», в таблице «230 В ±10 %», в чертеже другой разъём. Пятая — смешивание уровней: в спецификации закупки ламп прописывают внутренний технологический процесс завода, который заказчик не может и не должен контролировать.
Для новичка безопасный порядок работы такой. Сначала зафиксировать потребность простыми предложениями: что должен делать объект, в какой среде, с каким ресурсом и каким риском. Затем перевести каждое предложение в параметр и метод проверки. Далее сверить параметры с техническим регламентом и профильным ДСТУ. После этого дать текст прочитать человеку, который не участвовал в написании: если он задаёт уточняющие вопросы — формулировка ещё сырая.
- Проверяйте действительность ссылок. Стандарт с ошибочным годом или отменённое ТУ ломает и тендер, и приёмку партии.
- Отделяйте потребность от решения. «Обогреть помещение 40 м² до +20 °C» лучше, чем навязанная марка конкретного конвектора, если марка не является предметом унификации.
- Всегда добавляйте метод контроля. Без него требование существует только на бумаге.
- Фиксируйте версию документа. Устное «уточнённое» требование после объявления тендера или старта разработки порождает споры об объёме.
- Не собирайте лишних сертификатов. Требуйте только те подтверждения соответствия, которые вытекают из регламента или реальной потребности безопасности.
Для сложных систем полезно вести матрицу соответствия: строка — требование спецификации, столбцы — пункт договора, тест, ответственный, статус. Такая таблица не заменяет сам документ, но делает его пригодным к сопровождению после подписания.
Практический минимум для разных читателей
Пользователю-новичку достаточно трёх вопросов перед тем, как ставить подпись: понятно ли, что именно поставляют; можно ли это измерить; известно ли, кто и как подтвердит соответствие. Если хотя бы на один вопрос ответа нет, документ ещё не готов. Не стесняйтесь просить глоссарий и таблицу параметров вместо сплошного текста на десять страниц.
Продвинутому читателю стоит смотреть глубже: на трассировку требований, на согласованность с регламентом, на жизненный цикл после поставки. Спецификация, которая хорошо описывает приёмку и молчит об обслуживании, запасных частях, обновлении ПО или утилизации, переносит стоимость владения в серую зону. Для ИТ-команд отдельное внимание — к нефункциональным требованиям и наблюдаемости: логи, метрики, алерты, сценарий отката. Именно они отличают «систему, которую можно эксплуатировать» от «системы, которую как-то собрали».
Хорошо написанная техническая спецификация уменьшает пространство для домыслов. Плохо написанная превращает договор в постоянные переговоры о том, что «и так все понимали».
Отдельный слой — цифровые форматы. Спецификации всё чаще живут не только в PDF, а в системах управления требованиями, в BIM-моделях строительства, в репозиториях с контрольными списками приёмки. Содержание от этого не меняется: параметр, допуск, метод, ответственность. Меняется лишь скорость, с которой изменение в одной строке расходится всем участникам.
Когда спецификацию пишут совместно заказчик, профильный инженер и юрист, документ обычно выдерживает и тендер, и приёмку, и дальнейшую эксплуатацию. Когда его составляют «для галочки» из прошлого файла — он формально есть, но не выполняет свою единственную работу: сделать требования видимыми, общими и проверяемыми.
