ТЕХНІЧНЕ ЗАВДАННЯ. ВИМОГИ ДО ЗМІСТУ Й ОФОРМЛЕННЯ

Стандарт установлює порядок розробки й оформлення технічного завдання на проектування СОС (пристроїв, систем або програмних продуктів), незалежно від їх призначення й області застосування.

Технічне завдання (ТЗ) є важливим організаційним документом і має юридичний статус, тобто може бути пред'явлено при розгляді конфліктів у відповідній інстанції, наприклад, в суді. Тому складання і затвердження ТЗ має велике значення.

1. ЗАГАЛЬНІ ПОЛОЖЕННЯ

ТЗ розробляється для визначення призначення, виконуючих функцій, характеристик впливу оточуючого середовища, умов експлуатації та показників реакції об’єкта на дію зовнішніх факторів.

По суті, ТЗ є першим рівнем абстрактного відображення об’єкта чи системи з позиції користувача. Робота на стадії ТЗ проводиться в 3 етапи:

1. проведення НДР – загальний аналіз прототипів та шляхів розробки СОС;

2. розробка аванпроекту – загальний аналіз раціональних варіантів та структури СОС;

3. формування ТЗ на проектування – безпосередня розробка документа, в якому формулюють функціональні та параметричні вимоги до СОС та процесу його проектування.

ТЗ є основним та обов’язковим документом для початку робіт по створенню СОС та в кінці процесу проектування на етапі прийняття СОС.

• Технічне завдання оформляють відповідно до ДСТ 19.106-78 на аркушах формату 11 і 12 за ДСТ 2.301-68, як правило, без заповнення полів листа. Номера аркушів (сторінок) проставляються у верхній частині листа над текстом.

• Лист для затвердження і титульний лист оформляють відповідно до ДСТ 19.104-78. Інформаційну частину (анотацію і зміст), лист реєстрації змін допускається в документ не включати.

• Для внесення змін або доповнень у ТЗ на наступних стадіях розробки СОС випускають доповнення до нього. Узгодження і твердження доповнення до технічного завдання проводять в у такому ж порядку, що встановлений для технічного завдання.

Структура ТЗ визначається нормативними документами ( стандартами, розпорядженнями і т.п.) і, як правило, містить наступні елементи:

1. Титульний лист;

2. Вступ;

3. підстави для розробки;

4. призначення розробки;

5. мета розробки СОС;

6. характеристика процесу проектування або інформаційної технології;

7. вимоги до об’єкта проектування та до технічної (або програмної) документації (вимоги до забезпечень САПР);

8. техніко-економічні показники;

9. стадії й етапи розробки з термінами і витратами (якщо немає договору або контракту);

10. порядок випробувань, контролю і приймання;

11. джерела розробки та фінансування проекту;

12. список розробників ТЗ: як з боку замовника так і з боку розробника.

• У технічне завдання допускається включати додатки.

При необхідності внесення змін і доповнень, початкове ТЗ не міняють, а роблять документи у вигляді доповнень, змін до ТЗ або протоколів робочих нарад Замовника і Розробника. Ці документи розглядаються і затверджуються в тому ж порядку, що і основне ТЗ і мають статус невід'ємних частин ТЗ.

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

2. ЗМІСТ РОЗДІЛІВ

2.0. На титульному аркуші ТЗ повинно бути написано: Технічне завдання на <тема>. Також повинні бути підписи (і печатки) керівників проекту.

2.1. У розділі "Вступ" вказують найменування СОС та дають коротку характеристику області його застосування.

2.2. У розділі "Підстави для розробки" повинні бути зазначені:

- повний перелік нормативних документів, на підставі яких ведеться розробка;

- організація, що затвердила ці документи, і дати їх затвердження;

- найменування і (або) умовна позначка теми, в рамках якої здійснюється розробка СОС.

- також може подаватися наступна інформація: "в створенні системи беруть участь …", "фінансування робіт здійснює …", "початок робіт із створення …".

2.3. У розділі "Призначення розробки" повинна бути представлена загальна характеристика об’єкта проектування, яка включає:

- функціональне й експлуатаційне призначення СОС;

- загальний склад СОС;

- загальні умови застосування чи експлуатації об’єкта або програмного вироба.

2.4. У розділі "Мета розробки" описують мету створення СОС. Також може бути вказані критерії ефективності функціонування СОС.

2.5. У розділі "Характеристика процесу проектування" розміщують:

- загальний опис процесу проектування;

- вимоги до вхідних та вихідних даних на проектування.

2.6. Розділ "Вимоги до об’єкта проектування" повинний містити наступні підрозділи:

- вимоги до функціональних характеристик, які визначають структуру СОС; повинні бути зазначені вимоги до складу виконуваних функцій, організації вхідних і вихідних даних, тимчасових характеристик і т.д.

- вимоги до складу і параметрів технічних засобів; вказують необхідний склад технічних засобів з зазначенням їхніх основних технічних характеристик, а також визначають конкретні значення вхідних та вихідних параметрів СОС;

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

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

- вимоги до інформаційної і програмної сумісності; повинні бути зазначені вимоги до інформаційних структур на вході і виході і методам рішення, вихідним кодам, мовам програмування і програмних засобів, використовуваним програмою. При необхідності повинна забезпечуватися захист інформації і програмного забезпечення.

- вимоги до маркування та пакування; у загальному випадку указують вимоги до маркірування програмного виробу, варіанти і способи упакування.

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

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

- додаткові спеціальні вимоги.

Для задавання параметрів може складатись табличка такої форми:

№ п/п	Параметр	Позначення	Розмірність	Нотатки
1.	2.	3.	4.	5.
	Технічні параметри ...	...	...	...
	Економічні параметри ...	...	...	...
	Організаційні параметри ...	...	...	...

2.7. У розділі "Техніко-економічні показники" повинні бути зазначені:

- орієнтована економічна ефективність,

- передбачувана річна потреба,

- економічні переваги розробки в порівнянні з кращими вітчизняними і закордонними зразками або аналогами.

- інколи сюди вносять оцінку техніко-економічних показників функціонування СОС.

2.8. У розділі "Стадії й етапи розробки" обумовлюють і планують необхідні стадії розробки, етапи проектування в середині стадій і зміст робіт. Тут визначають терміни виконання робіт, виконавців та перелік документів, що повинні бути розроблені, погоджені і затверджені.

2.9. У розділі "Порядок випробувань, контролю і приймання" повинні бути зазначені види іспитів і загальні вимоги щодо приймання СОС.

2.10. У додатках до технічного завдання, при необхідності, приводять джерела розробки та фінансування проекту.

Під джерелами розробки розуміють:

- перелік науково-дослідних і інших робіт, що обґрунтовують розробку;

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

Як правило, при формуванні ТЗ не вдається повністю сформулювати всі вимоги до СОС, так як не завжди відома степінь можливості реалізації висунутих вимог. Така інформація з’являється лише на наступних стадіях проекту. В цьому випадку в ТЗ включають попередні формулювання вимог із зауваженням: «Дана вимога уточнююється на стадії...(конкретна стадія або етап робіт)». Після такої оцінки, уточнену вимогу включають в документ «Доповнення до ТЗ».

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