Технічна специфікація це документ, який фіксує вимірювані технічні вимоги до продукції, процесу, послуги чи системи так, щоб виконавець, замовник і контролер розуміли їх однаково. У законодавстві України це формулювання закріплене зокрема в Законі «Про технічні регламенти та оцінку відповідності»: специфікація встановлює вимоги, яким повинна задовольняти продукція, процес або послуга. У публічних закупівлях той самий термін означає сукупність технічних умов до предмета закупівлі — від функціоналу й безпечності до паковання, випробувань і впливу на довкілля.
На практиці документ працює як спільна система координат. Він не замінює стандарт і не є рекламним описом виробу: він відповідає на питання, яким саме параметрам має відповідати результат і як це перевірити. Від якості специфікації залежить, чи отримає замовник потрібний виріб, чи зможе підрядник коректно оцінити обсяг робіт і чи витримає проєкт перевірку відповідності.
Нижче розібрано юридичні та інженерні значення терміна, відмінності від технічного завдання, технічних умов і стандарту, типову структуру документа, критерії якісних вимог і типові помилки, які зривають тендери та розробку.
Що означає технічна специфікація в праві та інженерії
В українському праві термін живе в кількох шарах. Базове визначення дає Закон України від 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-моделях будівництва, у репозиторіях із контрольними списками приймання. Зміст від цього не змінюється: параметр, допуск, метод, відповідальність. Змінюється лише швидкість, з якою зміна в одному рядку розходиться всім учасникам.
Коли специфікацію пишуть спільно замовник, профільний інженер і юрист, документ зазвичай витримує і тендер, і приймання, і подальшу експлуатацію. Коли його складають «для галочки» з минулого файлу — він формально є, але не виконує свою єдину роботу: зробити вимоги видимими, спільними і перевірюваними.
