Тз на систему. Технічне завдання створення інформаційної системи

Технічне завданняна створення інформаційної системи

З ГОСТ 34.602-89
на написання ТЗ на автоматизовані системиуправління від 01.01.1990р.

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

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

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

1.3. Вимоги до ІС в обсязі, встановленому цим стандартом, можуть бути включені в завдання на проектування об'єкта інформатизації, що створюється. І тут ТЗ не розробляють.

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

1.5. У ТЗ включають ті вимоги, які доповнюють вимоги до систем даного виду і визначаються специфікою конкретного об'єкта, котрим створюється система.

1.6. Зміни до ТЗ оформлюють доповненням або підписаним замовником та розробником протоколом. Доповнення чи зазначений протокол є невід'ємною частиною ТЗ на ІС. На титульному аркуші ТЗ має бути запис “Діє з...”.

2. СКЛАД І ЗМІСТ

2.1. ТЗ містить такі розділи, які можуть бути поділені на підрозділи:

    загальні відомості;

    призначення та цілі створення (розвитку) системи;

    характеристика об'єктів;

    вимоги до системи;

    порядок контролю та приймання системи;

    вимоги до складу та змісту робіт з підготовки об'єкта розробки до введення системи у дію;

    вимоги до документування;

    Джерела розробки.
    До ТЗ можуть включатися додатки.

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

У ТЗ частини системи не включають розділи, дублюючі зміст розділів ТЗ загалом.

2.3. В розділі " Загальні відомості” вказують:

    повне найменування системи та її умовне позначення;

    шифр теми чи шифр (номер) договору;

    найменування компаній розробника та замовника (користувача) системи та їх реквізити;

    перелік документів, на підставі яких створюється система, ким і коли затверджено ці документи;

    планові терміни початку та закінчення роботи зі створення системи;

    відомості про джерела та порядок фінансування робіт;

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

2.4. Розділ "Призначення та цілі створення (розвитку) системи" складається з підрозділів:

    призначення системи;

    цілі створення системи.

2.4.1. У підрозділі "Призначення системи" вказують вид діяльності системи (управління, проектування тощо) та перелік об'єктів інформатизації (об'єктів), на яких передбачається її використовувати.

2.4.2. У підрозділі “Цілі створення системи” наводять найменування та необхідні значення технічних, технологічних, виробничо-економічних чи інших показників об'єкта інформатизації, які мають бути досягнуті внаслідок створення ІВ, та вказують критерії оцінки досягнення цілей створення системи.

2.5. У розділі "Характеристики об'єкту інформатизації" наводять:

    стислі відомості про об'єкт інформатизації або посилання на документи, що містять таку інформацію;

    відомості про умови експлуатації об'єкта автоматизації.

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

    вимоги до системи загалом;

    вимоги до функцій (завдань), що виконуються системою;

    вимоги до видів забезпечення.

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

2.6.1. У підрозділі "Вимоги до системи в цілому" вказують:

    вимоги до структури та функціонування системи;

    вимоги до чисельності та кваліфікації персоналу системи та режиму його роботи;

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

    вимоги до надійності;

    вимоги безпеки;

    вимоги до ергономіки та технічної естетики;

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

    вимоги щодо захисту інформації від несанкціонованого доступу;

    вимоги щодо збереження інформації при аваріях;

    вимоги щодо захисту від впливу зовнішніх впливів;

    вимоги до патентної чистоти;

    вимоги щодо стандартизації та уніфікації;

    Додаткові вимоги.

2.6.1.1. У вимогах до структури та функціонування системи наводять:

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

    вимоги до способів та засобів зв'язку для інформаційного обміну між компонентами системи;

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

    вимоги до режимів функціонування системи;

    вимоги щодо діагностування системи;

    перспективи розвитку, модернізації системи

2.6.1.2. У вимогах до чисельності та кваліфікації персоналу на ІВ наводять:

    вимоги до чисельності персоналу (користувачів) ІВ;

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

    потрібний режим роботи персоналу ІС.

2.6.1.3. У вимогах до показників призначення ІС наводять значення параметрів, що характеризують рівень відповідності системи її призначення.

2.6.1.4. До вимог до надійності включають:

    склад та кількісні значення показників надійності для системи в цілому або її підсистем;

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

    вимоги до надійності технічних засобівта програмного забезпечення;

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

2.6.1.5. До вимог безпеки включають вимоги щодо безпеки при постачанні, налагодженні, експлуатації та обслуговуванні системи.

2.6.1.6. До вимог з ергономіки та технічної естетики включають показники ІВ, що задають необхідну якість взаємодії людини з машиною та комфортність умов роботи персоналу.

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

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

2.6.1.9. У вимогах щодо патентної чистоти вказують перелік країн, щодо яких має бути забезпечена патентна чистота системи та її частин.

2.6.1.10. Додаткові вимоги включають спеціальні вимоги розробника або замовника системи.

2.6.2. У підрозділі "Вимога до функцій (завдань)", що виконується системою, наводять:

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

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

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

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

    перелік та критерії відмов для кожної функції, за якою задаються вимоги щодо надійності.

2.6.3. У підрозділі “Вимоги до видів забезпечення” залежно від виду системи наводять вимоги до математичного, інформаційного, лінгвістичного, програмного, технічного, метрологічного, організаційного, методичного та інших видів забезпечення системи.

2.6.3.2. Для інформаційного забезпечення системи наводять вимоги:

    до складу, структурі та способам організації даних у системі;

    до інформаційного обміну між компонентами системи;

    до інформаційної сумісності із суміжними системами;

    щодо застосування систем управління базами даних;

    до структури процесу збору, обробки, передачі даних у системі та подання даних;

    до захисту даних;

    до контролю, зберігання, оновлення та відновлення даних;

2.6.3.3. Для лінгвістичного забезпечення системи наводять вимоги до застосування у системі мов програмування високого рівня, мов взаємодії користувачів та технічних засобів системи, а також вимоги до кодування та декодування даних, до мов введення-виведення даних, мов маніпулювання даними, засобів опису предметної області, до способів організації діалогу.

2.6.3.4. Для програмного забезпечення системи наводять перелік покупних програмних засобів, а також вимоги:

    до залежності програмних засобів від операційного середовища;

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

2.6.3.5. Для технічного забезпечення системи наводять вимоги:

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

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

2.6.3.6. У вимогах до метрологічного забезпечення наводять:

    попередній перелік вимірювальних каналів;

    вимоги до точності вимірювань параметрів та (або) до метрологічних характеристик вимірювальних каналів;

    вимоги до метрологічної сумісності технічних засобів;

    перелік керуючих та обчислювальних каналів системи, для яких необхідно оцінювати точнісні характеристики;

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

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

2.6.3.7. Для організаційного забезпечення наводять вимоги:

    до структури та функцій підрозділів, які беруть участь у функціонуванні системи або забезпечують експлуатацію;

    до організації функціонування системи та порядку взаємодії персоналу ІВ та персоналу об'єкта інформатизації;

    до захисту від хибних дій персоналу системи.

2.7. Розділ “Склад та зміст робіт зі створення (розвитку) системи” повинен містити перелік стадій та етапів робіт зі створення системи, строки їх виконання, перелік організацій - виконавців робіт, посилання на документи, що підтверджують згоду цих організацій на участь у створенні системи, або запис , Що визначає відповідального (замовник або розробник) за проведення цих робіт.

У даному розділітакож наводять:

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

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

    програму робіт, спрямованих на забезпечення необхідного рівня надійності системи, що розробляється (при необхідності);

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

2.8. У розділі “Порядок контролю та приймання системи” вказують:

    види, склад, обсяг та методи випробувань системи та її складових частин;

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

2.9. У розділі "Вимоги до складу та змісту робіт з підготовки об'єкта автоматизації до введення системи в дію" необхідно привести перелік основних заходів та їх виконавців, які слід виконати під час підготовки проекту до введення ІС у дію.

До переліку основних заходів включають:

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

    створення умов функціонування проекту, у яких гарантується відповідність створюваної системи вимогам, які у ТЗ;

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

    терміни та порядок комплектування штатів та навчання персоналу.

2.10. У розділі "Вимоги до документування" наводять:

    погоджений розробником та Замовником системи перелік комплектів та видів документів, що підлягають розробці;
    перелік документів, що випускаються на машинних носіях;

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

2.11. У розділі “Джерела розробки” мають бути перераховані документи та інформаційні матеріали, на підставі яких розроблялося ТЗ та які мають бути використані під час створення системи.

3. ПРАВИЛА ОФОРМЛЕННЯ

3.1. Розділи та підрозділи ТЗ повинні бути розміщені у порядку, встановленому у розд. 2 цього стандарту.

3.2. Номери аркушів (сторінок) проставляють, починаючи з першого аркуша, наступного за титульним аркушем, у верхній частині аркуша (над текстом, посередині) після позначення коду ТЗ на ІВ.

3.3. На титульному аркуші розміщують підписи замовника, розробника та узгоджувальних компаній, які скріплюють печаткою. За потреби титульний лист оформляють на кількох сторінках. Підписи розробників ТЗ і посадових осіб, що у погодженні та розгляді проекту ТЗ на ІВ, поміщають останньому листе.

Форму титульного листа ТЗ наведено у додатку 2. Форму останнього листа ТЗ наведено у додатку 3.

3.4. Титульний лист доповнення до ТЗ оформляють аналогічно до титульного листа технічного завдання. Замість найменування "Технічне завдання" пишуть "Додаток №... до ТЗ на AC...".

3.5. На наступних аркушах доповнення до ТЗ поміщають основу зміни, зміст зміни та посилання документи, відповідно до якими вносяться ці зміни.

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

ПОРЯДОК РОЗРОБКИ, УГОДИ І ЗАТВЕРДЖЕННЯ ТЗ НА ІС

    Проект ТЗ розробляє організація-розробник системи за участю замовника на підставі технічних вимог(Заявки, тактико-технічного завдання тощо).
    При конкурсній організації робіт варіанти проекту ТЗ розглядаються замовником, який або вибирає кращий варіант, або на підставі порівняльного аналізу готує за участю майбутнього розробника ІВ остаточний варіант ТЗ на AC.

    Необхідність узгодження проекту ТЗ з органами державного нагляду та іншими заінтересованими організаціями визначають спільно замовник системи та розробник проекту ТЗ на ІВ,
    Роботу за погодженням проекту ТЗ на ІС здійснюють спільно розробник ТЗ та замовник системи, кожен в організаціях свого міністерства (відомства).

    Строк узгодження проекту ТЗ у кожній організації не повинен перевищувати 15 днів з дня його отримання. Рекомендується розсилати на узгодження екземпляри проекту ТЗ (копій) одночасно у всі організації (підрозділи).

    Зауваження щодо проекту ТЗ мають бути подані з технічним обґрунтуванням. Рішення щодо зауважень мають бути прийняті розробником проекту ТЗ та замовником системи до затвердження ТЗ на ІВ.

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

    Узгодження проекту ТЗ дозволяється оформляти окремим документом (листом). У цьому випадку під грифом "Узгоджено" роблять посилання на цей документ.

    Твердження ТЗ здійснюють керівники компаній розробника та замовника системи.

    Копії, затвердженого ТЗ у 10-денний термін після затвердження надсилаються розробником ТЗ учасникам створення системи.

    Узгодження та затвердження доповнень до ТЗ проводять у порядку, встановленому для ТЗ на ІВ.

    Зміни до ТЗ не допускається затверджувати після подання системи або її черги на приймально-здавальні випробування.

Цей стандарт поширюється на автоматизовані системи (АС) для автоматизації різних видів діяльності (управління, проектування, дослідження тощо), включаючи їх поєднання, та встановлює склад, зміст, правила оформлення документа «Технічне завдання на створення (розвиток чи модернізацію) системи» (далі – ТЗ на АС).
Рекомендований порядок розробки, погодження та затвердження ТЗ на АС наведено у додатку 1.

1. Загальні положення.

1.1. ТЗ на АС є основним документом, що визначає вимоги та порядок створення (розвитку чи модернізації - далі створення) автоматизованої системи, відповідно до якого проводиться розробка АС та її приймання при введенні в дію.
1.2. ТЗ на АС розробляють на систему в цілому, призначену для роботи самостійно або у складі іншої системи.
Додатково можуть бути розроблені ТЗ на частини АС: на підсистеми АС, комплекси завдань АС тощо відповідно до вимог цього стандарту; на комплектуючі засоби технічного забезпечення та програмно-технічні комплекси відповідно до стандартів ЕСКД та СРПП; на програмні засоби відповідно до стандартів ЄСПД; на інформаційні вироби відповідно до ГОСТ 19.201 та НТД, що діє у відомстві замовника АС.
Примітка.У ТЗ на АСУ для групи взаємозалежних об'єктів слід включати лише загальні для групи об'єктів вимоги. Специфічні вимоги окремого об'єкта управління слід відбивати у ТЗ на АСУ цього об'єкта.
1.3. Вимоги до АС в обсязі, встановленому цим стандартом, можуть бути включені в завдання на проектування об'єкта автоматизації, що створюється. І тут ТЗ на АС не розробляють.
1.4. Вимоги, що включаються до ТЗ на АС, повинні відповідати сучасному рівню розвитку науки і техніки і не поступатися аналогічним вимогам, що висуваються до кращих сучасних вітчизняних та зарубіжних аналогів.
Вимоги, що задаються в ТЗ на АС, не повинні обмежувати розробника системи у пошуку та реалізації найбільш ефективних технічних, техніко-економічних та інших рішень.
1.5. ТЗ на АС розробляють на підставі вихідних даних, у тому числі що містяться у підсумковій документації стадії «Дослідження та обґрунтування створення АС», встановленої ГОСТ 24.601.
1.6. У ТЗ на АС включають ті вимоги, які доповнюють вимоги до систем даного виду (АСУ, САПР, АСНІ тощо. буд.), які у діючих НТД, і визначаються специфікою конкретного об'єкта, котрій створюється система.
1.7. Зміни до ТЗ на АС оформлюють доповненням або підписаним замовником та розробником протоколом. Доповнення чи зазначений протокол є невід'ємною частиною ТЗ на АС. На титульному листі ТЗ на АС має бути запис «Діє з...».

2. Склад та зміст.

2.1. ТЗ на АС містить такі розділи, які можуть бути поділені на підрозділи:
1) загальні відомості;
2) призначення та цілі створення (розвитку) системи;
3) характеристика об'єктів автоматизації;
4) вимоги до системи;
5) склад та зміст робіт зі створення системи;
6) порядок контролю та приймання системи;
7) вимоги до складу та змісту робіт з підготовки об'єкта автоматизації до введення системи у дію;
8) вимоги до документування;
9) джерела розробки.
У ТЗ на АС можуть включатися додатки.
2.2. Залежно від виду, призначення, специфічних особливостей об'єкта автоматизації та умов (функціонування системи допускається оформляти розділи ТЗ у вигляді додатків, вводити додаткові, виключати чи об'єднувати підрозділи ТЗ).
У ТЗ частини системи не включають розділи, дублюючі зміст розділів ТЗ на АС загалом.
2.3. У розділі «Загальні відомості» вказують:
1) повне найменування системи та її умовне позначення;
2) шифр теми чи шифр (номер) договору;
3) найменування підприємств (об'єднань) розробника та замовника (користувача) системи та їх реквізити;
4) перелік документів, на підставі яких створюється система, ким і коли затверджено ці документи;
5) планові терміни початку та закінчення роботи зі створення системи;
6) відомості про джерела та порядок фінансування робіт;
7) порядок оформлення та пред'явлення замовнику результатів робіт зі створення системи (її частин), з виготовлення та налагодження окремих засобів (технічних, програмних, інформаційних) та програмно-технічних (програмно-методичних) комплексів системи.
2.4. Розділ «Призначення та цілі створення (розвитку) системи» складається з підрозділів:
1) призначення системи;
2) цілі створення системи.
2.4.1. У підрозділі «Призначення системи» вказують вид діяльності, що автоматизується (управління, проектування тощо) і перелік об'єктів автоматизації (об'єктів), на яких передбачається її використовувати.
Для АСУ додатково вказують перелік автоматизованих органів (пунктів) управління та керованих об'єктів.
2.4.2. У підрозділі «Цілі створення системи» наводять найменування та необхідні значення технічних, технологічних, виробничо-економічних чи інших показників об'єкта автоматизації, які мають бути досягнуті в результаті створення АС, та вказують критерії оцінки досягнення цілей створення системи.
2.5. У розділі "Характеристики об'єкта автоматизації" наводять:
1) стислі відомості про об'єкт автоматизації або посилання на документи, що містять таку інформацію;
2) відомості про умови експлуатації об'єкта автоматизація та характеристики навколишнього середовища.
Примітка:Для САПР у розділі додатково наводять основні параметри та характеристики об'єктів проектування.
2.6. Розділ «Вимоги до системи» складається з наступних підрозділів:
1) вимоги до системи загалом;
2) вимоги до функцій (завдань), що виконуються системою;
3) вимоги до видів забезпечення.
Склад вимог до системи, що включаються до цього розділу ТЗ на АС, встановлюють залежно від виду, призначення, специфічних особливостей та умов функціонування конкретної системи. У кожному підрозділі наводять посилання на НТД, що діють, що визначають вимоги до систем відповідного виду.
2.6.1. У підрозділі «Вимоги до системи загалом» вказують:

  • вимоги до структури та функціонування системи;
  • вимоги до чисельності та кваліфікації персоналу системи та режиму його роботи;
  • показники призначення;
  • вимоги до надійності;
  • вимоги безпеки;
  • вимоги до ергономіки та технічної естетики;
  • вимоги до транспортабельності для рухомих АС;
  • вимоги до експлуатації, технічного обслуговування, ремонту та зберігання компонентів системи;
  • вимоги щодо захисту інформації від несанкціонованого доступу;
  • вимоги щодо збереження інформації при аваріях;
  • вимоги щодо захисту від впливу зовнішніх впливів;
  • вимоги до патентної чистоти;
  • вимоги щодо стандартизації та уніфікації;
  • Додаткові вимоги.
26.1.1. У вимогах до структури та функціонування системи наводять:
а) перелік підсистем, їх призначення та основні характеристики, вимоги до рівнів ієрархії та ступеня централізації системи;
б) вимоги до способів та засобів зв'язку для інформаційного обміну між компонентами системи;
в) вимоги до характеристик взаємозв'язків створюваної системи із суміжними системами, вимоги до її сумісності, у тому числі вказівки про способи обміну інформацією (автоматично, пересиланням документів, телефоном тощо);
г) вимоги до режимів функціонування системи;
д) вимоги щодо діагностування системи;
е) перспективи розвитку, модернізації системи.
2.6.1.2. У вимогах до чисельності та кваліфікації персоналу та АС наводять:
а) вимоги до чисельності персоналу (користувачів) АС;
б) вимоги до кваліфікації персоналу, порядку його підготовки та контролю знань та навичок;
в) потрібний режим роботи персоналу АС.
2.6.1.3. У вимогах до показників призначення АС наводять значення параметрів, що характеризують рівень відповідності системи її призначення.
Для АСУ вказують:
а) ступінь адаптації системи до зміни процесів № методів управління, до відхилень параметрів об'єкта управління;
б) допустимі межі модернізації та розвитку системи;
в) вероятностно-часовые характеристики, у яких зберігається цільове призначення системи.
2.6.1.4. До вимог до надійності включають:
а) склад та кількісні значення показників надійності для системи в цілому або її підсистем;
б) перелік аварійних ситуацій, за якими мають бути регламентовані вимоги до надійності, та значення відповідних показників;
в) вимоги до надійності технічних засобів та програмного забезпечення;
г) вимоги до методів оцінки та контролю показників надійності на різних стадіях створення системи відповідно до чинних нормативно-технічних документів.
2.6.1.5. До вимог безпеки включають вимоги щодо безпеки при монтажі, налагодженні, експлуатації, обслуговуванні та ремонті технічних засобів системи (захист від впливів електричного струму, електромагнітних полів, акустичних шумів тощо), за допустимими рівнями освітленості, вібраційних та шумових навантажень.
2.6.1.6. До вимог з ергономіки та технічної естетики включають показники АС, що задають необхідну якість взаємодії людини з машиною та комфортність умов роботи персоналу.
2.6.1.7. Для рухомих АС вимоги до транспортабельності включають конструктивні вимоги, що забезпечують транспортабельність технічних засобів системи, а також вимоги до транспортним засобам.
2.6.1.8. До вимог до експлуатації, технічного обслуговування, ремонту та зберігання включають:
а) умови та регламент (режим) експлуатації, які повинні забезпечувати використання технічних засобів (ТЗ) системи із заданими технічними показниками, у тому числі види та періодичність обслуговування ТЗ системи або допустимість роботи без обслуговування;
б) попередні вимоги до допустимих площ для розміщення персоналу та ТЗ системи, до параметрів мереж енергопостачання тощо;
в) вимоги щодо кількості, кваліфікації обслуговуючого персоналу та режимів його роботи;
г) вимоги до складу, розміщення та умов зберігання комплекту запасних виробів та приладів;
д) вимоги до регламенту обслуговування.
2.6.1.9. До вимог захисту інформації від несанкціонованого доступу включають вимоги, встановлені в НТД, що діє в галузі (відомстві) замовника.
2.6.1.10. У вимогах щодо збереження інформації наводять перелік подій: аварій, відмов технічних засобів (у тому числі - втрата харчування) тощо, при яких має бути забезпечена безпека інформації в системі.
2.6.1.11. У вимогах до засобів захисту від зовнішніх впливів наводять:
а) вимоги до радіоелектронного захисту засобів АС;
б) вимоги щодо стійкості, стійкості та міцності до зовнішніх впливів (середовищу застосування).
2.6.1.12. У вимогах щодо патентної чистоти вказують перелік країн, щодо яких має бути забезпечена патентна чистота системи та її частин.
2.6.1.13. До вимог до стандартизації та уніфікації включають: показники, що встановлюють необхідний ступінь використання стандартних, уніфікованих методів реалізації функцій (завдань) системи, програмних засобів, що постачаються, типових математичних методів і моделей, типових проектних рішень, уніфікованих форм управлінських документів, встановлених ГОСТ 6.10.1, загальносоюзних класифікаторів техніко-економічної інформації та класифікаторів інших категорій відповідно до сфери їх застосування, вимоги до використання типових автоматизованих робочих місць, компонентів та комплексів.
2.6.1.14. Додаткові вимоги включають:
а) вимоги щодо оснащення системи пристроями для навчання персоналу (тренажерами, іншими пристроями аналогічного призначення) та документацією на них;
б) вимоги до сервісної апаратури, стендів для перевірки елементів системи;
в) вимоги до системи, пов'язані з особливими умовамиексплуатації;
г) спеціальні вимоги щодо розсуду розробника чи замовника системи.
2.6.2. У підрозділі «Вимога до функцій (завдань)», що виконується системою, наводять:
а) за кожною підсистемою перелік функцій, завдань чи їх комплексів (зокрема які забезпечують взаємодію частин системи), підлягають автоматизації;
при створенні системи у дві або більше черги - перелік функціональних підсистем, окремих функцій або завдань, що вводяться в дію у 1-й та наступних чергах;
б) тимчасовий регламент реалізації кожної функції, завдання (або комплексу завдань);
в) вимоги до якості реалізації кожної функції (завдання чи комплексу завдань), до форми подання вихідної інформації, характеристики необхідної точності та часу виконання, вимоги одночасності виконання групи функцій, достовірності видачі результатів;
г) перелік та критерії відмов для кожної функції, за якою задаються вимоги щодо надійності.
2.6.3. У підрозділі «Вимоги до видів забезпечення» залежно від виду системи наводять вимоги до:
1) математичному,
2) інформаційному,
3) лінгвістичному,
4) програмному,
5) технічному,
6) метрологічне,
7) організаційному,
8) методичного та інших видів забезпечення системи.
2.6.3.1. Для математичного забезпечення системи наводять вимоги до складу, галузі застосування (обмеження) та способів, використання в системі математичних методів та моделей, типових алгоритмів та алгоритмів, що підлягають розробці.
2.6.3.2. Для інформаційного забезпечення: системи наводять вимоги:
а) до складу, структури та способів організації даних у системі;
б) до інформаційного обміну між компонентами системи;
в) до інформаційної сумісності із суміжними системами;
г) щодо використання загальносоюзних та зареєстрованих республіканських, галузевих класифікаторів, уніфікованих документів та класифікаторів, що діють на даному підприємстві;
д) щодо застосування систем управління базами даних;
е) до структури процесу збору, обробки, передачі даних у системі та подання даних;
ж) до захисту даних від руйнувань при аваріях та збоях в електроживленні системи;
з) до контролю, зберігання, оновлення та відновлення даних;
і) до процедури надання юридичної сили документам, які продукуються технічними засобами АС (відповідно до ГОСТ 6.10.4).
2.6.3.3. Для лінгвістичного забезпечення системи наводять вимоги до застосування в системі мов програмування високого рівня, мов взаємодії користувачів та технічних засобів системи, а також вимоги до кодування та декодування даних, до мов введення-виведення даних, мов маніпулювання даними, засобів опису предметної області (об'єкта автоматизації ), до способів організації діалогу.
2.6.3.4. Для програмного забезпечення системи наводять перелік покупних програмних засобів, а також вимоги:
а) до незалежності програмних засобів від використовуваних СБТ та операційного середовища;
б) до якості програмних засобів, а також до способів його забезпечення та контролю;
в) за необхідністю узгодження програмних засобів, що знову розробляються, з фондом алгоритмів і програм.
2.6.3.5. Для технічного забезпечення системи наводять вимоги:
а) до видів технічних засобів, у тому числі до видів комплексів технічних засобів, програмно-технічних комплексів та інших комплектуючих виробів, допустимих для використання у системі;
б) до функціональних, конструктивних та експлуатаційних характеристик засобів технічного забезпечення системи.
2.6.3.6. У вимогах до метрологічного забезпечення наводять:
а) попередній перелік вимірювальних каналів;
б) вимоги до точності вимірювань параметрів та (або) до метрологічних характеристик вимірювальних каналів;
в) вимоги до метрологічної сумісності технічних засобів;
г) перелік керуючих та обчислювальних каналів системи, для яких необхідно оцінювати точнісні характеристики;
д) вимоги до метрологічного забезпечення технічних та програмних засобів, що входять до складу вимірювальних каналів системи, засобів вбудованого контролю, метрологічної придатності вимірювальних каналів та засобів вимірювань, що використовуються під час налагодження та випробування системи;
е) вид метрологічної атестації (державна чи відомча) із зазначенням порядку її виконання та організацій, які проводять атестацію.
2.6.3.7. Для організаційного забезпечення наводять вимоги:
а) до структури та функцій підрозділів, які беруть участь у функціонуванні системи або забезпечують експлуатацію;
б) до організації функціонування системи та порядку взаємодії персоналу АС та персоналу об'єкта автоматизації;
в) до захисту від хибних дій персоналу системи.
2.6.3.8. Для методичного забезпечення САПР наводять вимоги до складу нормативно-технічної документації системи (перелік застосовуваних під час її функціонування стандартів, нормативів, методик тощо).
2.7. Розділ «Склад та зміст робіт зі створення (розвитку) системи» повинен містити перелік стадій та етапів робіт зі створення системи відповідно до ГОСТ 24.601, строки їх виконання, перелік організацій-виконавців робіт, посилання на документи, що підтверджують згоду цих організацій на участь у створення системи, або запис, що визначає відповідального (замовник або розробник) за проведення цих робіт.
У цьому розділі також наводять:
1) перелік документів, за ГОСТ 34.201, що пред'являються після закінчення відповідних стадій та етапів робіт;
2) вид та порядок проведення експертиза технічної документації (стадія, етап, обсяг документації, що перевіряється, організація-експерт);
3) програму робіт, спрямованих на забезпечення необхідного рівня надійності системи, що розробляється (при необхідності);
4) перелік робіт з метрологічного забезпечення на всіх стадіях створення системи із зазначенням їх термінів виконання та організацій-виконавців (при необхідності).
2.8. У розділі «Порядок контролю та приймання системи» вказують:
1) види, склад, обсяг і методи випробувань системи та її складових частин (види випробувань відповідно до чинних норм, що поширюються на систему, що розробляється);
2) загальні вимоги до приймання робіт по стадіях (перелік підприємств і організацій, що беруть участь, місце і строки проведення), порядок погодження та затвердження приймальної документації;
З) статус приймальної комісії (державна, міжвідомча, відомча).
2.9. У розділі «Вимоги до складу та змісту робіт з підготовки об'єкта автоматизації до введення системи в дію» необхідно навести перелік основних заходів та їх виконавців, які слід виконати під час підготовки об'єкта автоматизації до введення АС у дію.
До переліку основних заходів включають:
1) приведення інформації, що надходить до системи (відповідно до вимог до інформаційного та лінгвістичного забезпечення) до виду, придатного для обробки за допомогою ЕОМ;
2) зміни, які необхідно здійснити в об'єкті автоматизації;
3) створення умов функціонування об'єкта автоматизації, у яких гарантується відповідність створюваної системи вимогам, які у ТЗ;
4) створення необхідних для функціонування системи підрозділів та служб;
5) терміни та порядок комплектування штатів та навчання персоналу.
Наприклад, для АСУ наводять:
  • зміни застосовуваних методів управління;
  • створення умов роботи компонентів АСУ, у яких гарантується відповідність системи вимогам, які у ТЗ.

2.10. У розділі "Вимоги до документування" наводять:
1) узгоджений розробником та замовником системи перелік комплектів та видів документів, що підлягають розробці, відповідних вимогам ГОСТ 34.201 та НТД галузі замовника; перелік документів, що випускаються на машинних носіях; вимоги до мікрофільмування документації;
2) вимоги щодо документування комплектуючих елементів міжгалузевого застосування відповідно до вимог ЄСКД та ЕСПД;
3) за відсутності державних стандартів, що визначають вимоги до документування елементів системи, додатково включають вимоги до складу та змісту таких документів.
2.11. У розділі «Джерела розробки» мають бути перераховані документи та інформаційні матеріали (техніко-економічне обґрунтування, звіти про закінчені науково-дослідні роботи, інформаційні матеріали на вітчизняні, зарубіжні системи-аналоги та ін.), на підставі яких розроблялося ТЗ та які мають бути використані під час створення системи.
2.12. До складу ТЗ на АС за наявності затверджених методик включають додатки, що містять:
а) розрахунок очікуваної ефективності системи;
б) оцінку науково-технічного рівня системи.
Програми включають до складу ТЗ на АС за погодженням між розробником та замовником системи.

3. ПРАВИЛА ОФОРМЛЕННЯ

3.1. Розділи та підрозділи ТЗ на АС повинні бути розміщені у порядку, встановленому у розд. 2 цього стандарту.
3.2. ТЗ на АС оформлюють відповідно до вимог ГОСТ 2.105 на аркушах формату А4 за ГОСТ 2.301 без рамки, основного напису та додаткових граф до неї.
Номери аркушів (сторінок) проставляють, починаючи з першого аркуша, наступного за титульним аркушем, у верхній частині аркуша (над текстом, посередині) після позначення коду ТЗ на АС.
3.3. Значення показників, норм та вимог вказують, як правило, з граничними відхиленнями або максимальним та мінімальним значеннями. Якщо ці показники, норми, вимоги однозначно регламентовані НТД, у ТЗ на АС слід наводити посилання на ці документи або їх розділи, а також додаткові вимоги, що враховують особливості системи, що створюється. Якщо конкретні значення показників, норм та вимог не можуть бути встановлені в процесі розробки ТЗ на АС, у ньому слід зробити запис про порядок встановлення та узгодження цих показників, норм та вимог:
«Остаточна вимога (значення) уточнюється у процесі ….. та узгоджується протоколом с.…… на стадії ……..». При цьому текст ТЗ на АС змін не вносять.
3.4. На титульному аркуші розміщують підписи замовника, розробника та узгоджувальних організацій, які скріплюють гербовою печаткою. За потреби титульний лист оформляють на кількох сторінках. Підписи розробників ТЗ на АС та посадових осіб, які беруть участь у погодженні та розгляді проекту ТЗ на АС, поміщають на останньому аркуші.
Форму титульного листа ТЗ на АС наведено в додатку 2. Форма останнього аркуша ТЗ на АС наведена в додатку 3.
3.5. За потреби на титульному листі ТЗ на АС допускається розміщувати встановлені в галузі коди, наприклад: гриф секретності, код роботи, реєстраційний номер ТЗ та ін.
3.6. Титульний лист доповнення до ТЗ на АС оформляють аналогічно титульному аркушу технічного завдання. Замість найменування «Технічне завдання» пишуть «Додаток №… до ТЗ на AC…».
3.7. На наступних аркушах доповнення до ТЗ на АС поміщають підставу для зміни, зміст зміни та посилання на документи, відповідно до яких вносяться ці зміни.
3.8. При викладанні тексту доповнення до ТЗ слід зазначати номери відповідних пунктів, підпунктів, таблиць основного ТЗ на АС тощо і застосовувати слова: «замінити», «доповнити», «виключити», «викласти у новій, редакції».

Додаток 1. (Рекомендований) ПОРЯДОК РОЗРОБКИ, УГОДИ ТА ЗАТВЕРДЖЕННЯ ТЗ НА АС

1. Проект ТЗ на АС розробляє організація-розробник системи за участю замовника на підставі технічних вимог (заявки; тактико-технічного завдання тощо).
При конкурсній організації робіт варіанти проекту ТЗ на АС розглядаються замовником, який або вибирає кращий варіант, або на підставі порівняльного аналізу готує за участю майбутнього розробника АС остаточний варіант ТЗ на AC.
2. Необхідність узгодження проекту ТЗ на АС з органами державного нагляду та іншими заінтересованими організаціями визначають спільно замовник системи та розробник проекту ТЗ на АС.
Роботу за погодженням проекту ТЗ на AC здійснюють спільно розробник ТЗ на АС та замовник системи, кожен в організаціях свого міністерства (відомства).
3. Строк погодження проекту ТЗ на АС у кожній організації не повинен перевищувати 15 днів з дня його отримання. Рекомендується розсилати на узгодження екземпляри проекту ТЗ на АС (копій) одночасно у всі організації (підрозділи).
4. Зауваження щодо проекту ТЗ на АС мають бути подані з технічним обґрунтуванням. Рішення щодо зауважень мають бути прийняті розробником проекту ТЗ на АС та замовником системи до затвердження ТЗ на АС.
5. Якщо за погодженням проекту ТЗ на АС виникли розбіжності між розробником та замовником (або іншими зацікавленими організаціями), то складається протокол розбіжностей (форма довільна) та конкретне рішення приймається в установленому порядку.
6. Узгодження проекту ТЗ на АС дозволяється оформляти окремим документом (листом). У цьому випадку під грифом "Узгоджено" роблять посилання на цей документ.
7. Затвердження ТЗ на АС здійснюють керівники підприємств (організацій) розробника та замовника системи.
8. ТЗ на АС (додаток до ТЗ) до передачі його на затвердження має бути перевірено службою нормоконтролю організації - розробника ТЗ та, за необхідності, піддано метрологічній експертизі.
9. Копії затвердженого ТЗ на АС у 10-денний строк після затвердження надсилаються розробником ТЗ на АС учасникам створення системи.
10. Узгодження та затвердження доповнень до ТЗ на АС проводять у порядку, встановленому для ТЗ на АС.
11. Зміни до ТЗ на АС не допускається затверджувати після подання системи для її черги на приймально-здавальні випробування.
12. Реєстрація, облік та зберігання ТЗ на АС та доповнень до нього проводять відповідно до вимог ГОСТ 2.501.


найменування організації – розробника ТЗ на АС

________________________________________________________
найменування виду АС
________________________________________________________
найменування об'єкта автоматизації
________________________________________________________
скорочене найменування АС

ТЕХНІЧНЕ ЗАВДАННЯ
На ____ аркушах

Діє з
ПОГОДЖЕНО
Керівник (посада, найменування узгоджувальної організації)
Особистий підпис __________ Розшифровка підпису _______________
печатка
Дата

____________________________________
(код ТЗ)

Склали

ПОГОДЖЕНО

додаток(Довідкова) Положення щодо створення єдиного комплексу стандартів автоматизованих систем.

1. Вихідні передумови створення комплексу
1.1. Створення та впровадження автоматизованих систем різних класів та призначень ведеться у багатьох галузях промисловості з нормативно-технічної документації, що встановлює різноманітні організаційно-методичні та технічні норми, правила та положення, що ускладнюють інтеграцію систем та ефективне їх спільне функціонування.
1.2. У період ухвалення Держстандартом СРСР рішення про вдосконалення міжгалузевих комплексів стандартів діяли такі комплекси та системи стандартів, що встановлюють вимоги до різних видів АС:
1) єдина системастандартів автоматизованих систем управління (24 система), що поширюється на АСУ, АСУП, АСУ ТП та інші організаційно-економічні системи;
2) комплекс стандартів (система 23501); що поширюються на системи автоматизованого проектування;
3) четверта група 14 системи стандартів, що поширюється на автоматизовані системи технологічної підготовки виробництва.
1.3. Практика застосування стандартів на АСУ, САПР, АСУ ТП, АСТПП показала, що в них застосовується однаковий понятійний апарат, є багато загальних об'єктів стандартизації, проте вимоги стандартів не узгоджені між собою, є відмінності за складом та змістом робіт, відмінності за позначенням, складом, змісту та оформлення документів та ін.
1.4. На тлі відсутності єдиної технічної політикиу сфері створення АС різноманіття стандартів не забезпечувало широкої сумісності АС за її взаємодії, не дозволяло тиражувати системи, гальмувало розвиток перспективних напрямів використання засобів обчислювальної техніки.
1.5. В даний час здійснюється перехід до створення складних АС (за кордоном системи CAD – САМ), що включають до свого складу АСУ технологічними процесами та виробництвами, САПР – конструктора, САПР – технолога, АСНІ та ін. системи. Використання суперечливих правил під час створення таких систем призводить до зниження якості, збільшення вартості робіт, затягування термінів введення АС у дію.
1.6. Єдиний комплексстандартів та керівних документів має поширюватися на автоматизовані системи різного призначення: АСНІ, САПР, ОАСУ, АСУП, АСУТП, АСУГПС, АСК, АСТПП, включаючи їхню інтеграцію.
1.7. При розробці міжгалузевих документів слід враховувати такі особливості АС як об'єктів стандартизації:
1) технічне завдання є основним документом, відповідно до якого проводять створення АС та приймання його замовником;
2) АС, як правило, створюють проектним шляхом з комплектацією виробами серійного та одиничного виробництва та проведенням будівельних, монтажних, налагоджувальних та пускових робіт, необхідних для введення в дію АС;
3) у загальному випадку АС (підсистема АС) складається з програмно-технічних (ПТК), програмно-методичних комплексів (ПМК) та компонентів технічного, програмного та інформаційного забезпечення.
Компоненти цих видів забезпечення, а також ПМК та ПТК повинні виготовлятися та поставлятися як продукція виробничо-технічного призначення. Компоненти можуть входити в АС як самостійні частини або можуть бути об'єднані в комплекси;
4) створення АС в організаціях (підприємствах) потребує спеціальної підготовки користувачів та обслуговуючого персоналу системи;
5) функціонування АС та комплексів забезпечується сукупністю організаційно-методичних документів, що розглядаються у процесі створення як компоненти правового, методичного, лінгвістичного, математичного, організаційного та інших видів забезпечення. Окремі рішення, одержувані у процесі розробки цих забезпечень, можуть реалізовуватися як компонентів технічного, програмного чи інформаційного забезпечення;
6) спільне функціонування та взаємодія різних систем та комплексів здійснюється на базі локальних мережЕОМ.
Специфікації та угоди, прийняті для локальних мереж ЕОМ, обов'язкові для забезпечення сумісності систем, комплексів і компонентів.
Взаємозв'язок ЕКС АС з іншими системами та комплексами стандартів.
2.1. Стандартизація в галузі АС є складовою робіт з узагальненої проблеми «Інформаційна технологія».
2.2. Єдиний комплекс стандартів керівних документів на автоматизовані системи спільно з іншими системами та комплексами стандартів має утворювати повне нормативно-технічне забезпечення процесів створення та функціонування АС.
2.3. ЕКС АС повинен охоплювати специфічні для автоматизованих систем напрями стандартизації та поширювати традиційні напрями стандартизації на програмно-технічні, програмно-методичні комплекси та автоматизовані системи загалом.
2.4. Напрями та завдання стандартизації при нормативно-технічному забезпеченні процесів створення та функціонування АС групують наступним чином:
1) встановлення технічних вимог до продукції;
2) регламентація методів випробувань та правил атестації та сертифікації продукції;
3) регламентація правил та порядку розробки;
4) встановлення правил документування;
5) забезпечення сумісності;
6) регламентація організаційно-методичних питань функціонування систем.
Напрямки 1-4 є традиційними при розробці, виготовленні та постачанні продукції. Напрямки 5, 6 є специфічними і випливають із особливостей, властивих АС.
2.5. Забезпеченість АС загалом та його складових частин нормативно-технічної документацією у межах прийнятих напрямів і завдань стандартизації різна.
Компоненти технічного, програмного та інформаційного забезпечення як продукцію виробничо-технічного призначення розглядають, відповідно, як конструкторські, програмні та інформаційні вироби. На ці вироби поширюються комплекси стандартів ЕСКД, що діють. СРПП, ЕСПД, СДІП, УСД, класифікатори та кодифікатори техніко-економічної інформації, комплекси стандартів виду «ОТТ», «Методи випробувань», «ТУ», а також ОТТ замовника.
2.5.1. Весь життєвий цикл конструкторських виробів повністю забезпечений нормативно-технічною документацією, що діє у машинобудуванні та приладобудуванні.
2.5.2. Програмні вироби забезпечені НТД, що входить до ЕСПД та ВТТ замовника. Однак область поширення цих НТД має бути розширена з метою відображення питань, пов'язаних із розробкою, створенням, розповсюдженням та експлуатацією програмних виробів.
2.5.3. Інформаційні вироби нині не забезпечені НТД, хоча окремі питання опрацьовані у межах УСД, класифікаторах і кодифікаторах техніко-економічної інформації.
2.6. Програмно-технічні та програмно-методичні комплекси розглядаються як складні вироби, які не мають аналогів у машинобудуванні. Враховуючи статус ПТК та ПМК. як продукції виробничо-технічного призначення, правила та порядок їх розробки має бути аналогічним вимогам, встановленим стандартами системи розробки та постановки продукції на виробництво (СРПП).


Information technologies. Набір стандартів для автоматизованих систем. Technical directions для розвитку автоматизованої системи

З ГОСТ 34.602-89 на написання ТЗ на автоматизовані системи управління від 01.01.1990р.

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

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

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

1.3. Вимоги до ІС в обсязі, встановленому цим стандартом, можуть бути включені в завдання на проектування об'єкта інформатизації, що створюється. І тут ТЗ не розробляють.

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

1.5. У ТЗ включають ті вимоги, які доповнюють вимоги до систем даного виду і визначаються специфікою конкретного об'єкта, котрим створюється система.

1.6. Зміни до ТЗ оформлюють доповненням або підписаним замовником та розробником протоколом. Доповнення чи зазначений протокол є невід'ємною частиною ТЗ на ІС. На титульному аркуші ТЗ має бути запис «Діє з...».

2. СКЛАД І ЗМІСТ

2.1. ТЗ містить такі розділи, які можуть бути поділені на підрозділи:

  • 1) загальні відомості;

  • 2) призначення та цілі створення (розвитку) системи;

  • 3) характеристика об'єктів;

  • 4) вимоги до системи;

  • 5) склад та зміст робіт зі створення системи;

  • 6) порядок контролю та приймання системи;

  • 7) вимоги до складу та змісту робіт з підготовки об'єкта розробки до введення системи у дію;

  • 8) вимоги до документування;

  • 9) джерела розробки.
До ТЗ можуть включатися додатки.

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

У ТЗ частини системи не включають розділи, дублюючі зміст розділів ТЗ загалом.

2.3. У розділі «Загальні відомості» вказують:


  • 1) повне найменування системи та її умовне позначення;

  • 2) шифр теми чи шифр (номер) договору;

  • 3) найменування компаній розробника та замовника (користувача) системи та їх реквізити;

  • 4) перелік документів, на підставі яких створюється система, ким і коли затверджено ці документи;

  • 5) планові терміни початку та закінчення роботи зі створення системи;

  • 6) відомості про джерела та порядок фінансування робіт;

  • 7) порядок оформлення та пред'явлення замовнику результатів робіт зі створення системи (її частин), з виготовлення та налагодження окремих засобів (технічних, програмних, інформаційних) та програмно-технічних (програмно-методичних) комплексів системи.
2.4. Розділ «Призначення та цілі створення (розвитку) системи» складається з підрозділів:

  • 1) призначення системи;

  • 2) цілі створення системи.
2.4.1. У підрозділі «Призначення системи» вказують вид діяльності системи (управління, проектування тощо) та перелік об'єктів інформатизації (об'єктів), на яких передбачається її використовувати.

2.4.2. У підрозділі «Цілі створення системи» наводять найменування та необхідні значення технічних, технологічних, виробничо-економічних чи інших показників об'єкта інформатизації, які мають бути досягнуті внаслідок створення ІВ, та вказують критерії оцінки досягнення цілей створення системи.

2.5. У розділі "Характеристики об'єкту інформатизації" наводять:


  • 1) стислі відомості про об'єкт інформатизації або посилання на документи, що містять таку інформацію;

  • 2) відомості про умови експлуатації об'єкта автоматизації.
2.6. Розділ «Вимоги до системи» складається з наступних підрозділів:

  • 1) вимоги до системи загалом;

  • 2) вимоги до функцій (завдань), що виконуються системою;

  • 3) вимоги до видів забезпечення.
Склад вимог до системи, що включаються до цього розділу ТЗ на ІВ, встановлюють залежно від виду, призначення, специфічних особливостей та умов функціонування конкретної системи.

2.6.1. У підрозділі «Вимоги до системи загалом» вказують:


  • вимоги до структури та функціонування системи;

  • вимоги до чисельності та кваліфікації персоналу системи та режиму його роботи;

  • показники призначення;

  • вимоги до надійності;

  • вимоги безпеки;

  • вимоги до ергономіки та технічної естетики;

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

  • вимоги щодо захисту інформації від несанкціонованого доступу;

  • вимоги щодо збереження інформації при аваріях;

  • вимоги щодо захисту від впливу зовнішніх впливів;

  • вимоги до патентної чистоти;

  • вимоги щодо стандартизації та уніфікації;

  • Додаткові вимоги.
2.6.1.1. У вимогах до структури та функціонування системи наводять:

  • 1) перелік підсистем, їх призначення та основні характеристики, вимоги до рівнів ієрархії та ступеня централізації системи;

  • 2) вимоги до способів та засобів зв'язку для інформаційного обміну між компонентами системи;

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

  • 4) вимоги до режимів функціонування системи;

  • 5) вимоги щодо діагностування системи;

  • 6) перспективи розвитку, модернізації системи.
2.6.1.2. У вимогах до чисельності та кваліфікації персоналу на ІВ наводять:

  • вимоги до чисельності персоналу (користувачів) ІВ;

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

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

2.6.1.4. До вимог до надійності включають:


  • 1) склад та кількісні значення показників надійності для системи в цілому або її підсистем;

  • 2) перелік аварійних ситуацій, за якими мають бути регламентовані вимоги до надійності, та значення відповідних показників;

  • 3) вимоги до надійності технічних засобів та програмного забезпечення;

  • 4) вимоги до методів оцінки та контролю показників надійності на різних стадіях створення системи відповідно до чинних нормативно-технічних документів.
2.6.1.5. До вимог безпеки включають вимоги щодо безпеки при постачанні, налагодженні, експлуатації та обслуговуванні системи.

2.6.1.6. До вимог з ергономіки та технічної естетики включають показники ІВ, що задають необхідну якість взаємодії людини з машиною та комфортність умов роботи персоналу.

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

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

2.6.1.9. У вимогах щодо патентної чистоти вказують перелік країн, щодо яких має бути забезпечена патентна чистота системи та її частин.

2.6.1.10. Додаткові вимоги включають спеціальні вимоги розробника або замовника системи.

2.6.2. У підрозділі «Вимога до функцій (завдань)», що виконується системою, наводять:


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

  • при створенні системи у дві або більше черги - перелік функціональних підсистем, окремих функцій або завдань, що вводяться в дію у 1-й та наступних чергах;

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

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

  • перелік та критерії відмов для кожної функції, за якою задаються вимоги щодо надійності.
2.6.3. У підрозділі «Вимоги до видів забезпечення» залежно від виду системи наводять вимоги до математичного, інформаційного, лінгвістичного, програмного, технічного, метрологічного, організаційного, методичного та інших видів забезпечення системи.

2.6.3.2. Для інформаційного забезпечення системи наводять вимоги:


  • 1) до складу, структури та способів організації даних у системі;

  • 2) до інформаційного обміну між компонентами системи;

  • 3) до інформаційної сумісності із суміжними системами;

  • 4) щодо застосування систем управління базами даних;

  • 5) до структури процесу збору, обробки, передачі даних у системі та подання даних;

  • 6) до захисту даних;

  • 7) до контролю, зберігання, оновлення та відновлення даних;
2.6.3.3. Для лінгвістичного забезпечення системи наводять вимоги до застосування в системі мов програмування високого рівня, мов взаємодії користувачів та технічних засобів системи, а також вимоги до кодування та декодування даних, до мов введення-виведення даних, мов маніпулювання даними, засобів опису предметної області, до способів організації діалогу.

2.6.3.4. Для програмного забезпечення системи наводять перелік покупних програмних засобів, а також вимоги:


  • 1) до залежності програмних засобів від операційного середовища;

  • 2) до якості програмних засобів, а також до способів його забезпечення та контролю;
2.6.3.5. Для технічного забезпечення системи наводять вимоги:

  • 1) до видів технічних засобів, у тому числі до видів комплексів технічних засобів, програмно-технічних комплексів та інших комплектуючих виробів, допустимих для використання у системі;

  • 2) до функціональних, конструктивних та експлуатаційних характеристик засобів технічного забезпечення системи.
2.6.3.6. У вимогах до метрологічного забезпечення наводять:

  • 1) попередній перелік вимірювальних каналів;

  • 2) вимоги до точності вимірювань параметрів та (або) до метрологічних характеристик вимірювальних каналів;

  • 3) вимоги до метрологічної сумісності технічних засобів;

  • 4) перелік управляючих та обчислювальних каналів системи, для яких необхідно оцінювати точнісні характеристики;

  • 5) вимоги до метрологічного забезпечення технічних та програмних засобів, що входять до складу вимірювальних каналів системи, засобів, вбудованого контролю, метрологічної придатності вимірювальних каналів та засобів вимірювань, що використовуються під час налагодження та випробування системи;

  • 6) вид метрологічної атестації (державна чи відомча) із зазначенням порядку її виконання та організацій, які проводять атестацію.
2.6.3.7. Для організаційного забезпечення наводять вимоги:

 1) до структури та функцій підрозділів, які беруть участь у функціонуванні системи або забезпечують експлуатацію;

 2) до організації функціонування системи та порядку взаємодії персоналу ІВ та персоналу об'єкта інформатизації;

 3) захист від помилкових дій персоналу системи.

2.7. Розділ «Склад та зміст робіт зі створення (розвитку) системи» повинен містити перелік стадій та етапів робіт зі створення системи, строки їх виконання, перелік організацій - виконавців робіт, посилання на документи, що підтверджують згоду цих організацій на участь у створенні системи, або запис , Що визначає відповідального (замовник або розробник) за проведення цих робіт.

У цьому розділі також наводять:


  • 1) перелік документів, що пред'являються після закінчення відповідних стадій та етапів робіт;

  • 2) вид та порядок проведення експертизи технічної документації (стадія, етап, обсяг документації, що перевіряється, організація-експерт);

  • 3) програму робіт, спрямованих на забезпечення необхідного рівня надійності системи, що розробляється (при необхідності);

  • 4) перелік робіт з метрологічного забезпечення на всіх стадіях створення системи із зазначенням їх термінів виконання та організацій-виконавців (при необхідності).
2.8. У розділі «Порядок контролю та приймання системи» вказують:

  • 1) види, склад, обсяг та методи випробувань системи та її складових частин;

  • 2) загальні вимоги до приймання робіт по стадіях, порядок погодження та затвердження приймальної документації;
2.9. У розділі «Вимоги до складу та змісту робіт з підготовки об'єкта автоматизації до введення системи в дію» необхідно навести перелік основних заходів та їх виконавців, які слід виконати під час підготовки проекту до введення ІС у дію.

До переліку основних заходів включають:


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

  • 2) створення умов функціонування проекту, у яких гарантується відповідність створюваної системи вимогам, які у ТЗ;

  • 3) створення необхідних для функціонування системи підрозділів та служб;

  • 4) терміни та порядок комплектування штатів та навчання персоналу.
2.10. У розділі "Вимоги до документування" наводять:

  • 1) узгоджений розробником та Замовником системи перелік комплектів та видів документів, що підлягають розробці;
    перелік документів, що випускаються на машинних носіях;

  • 2) за відсутності державних стандартів, що визначають вимоги до документування елементів системи, додатково включають вимоги до складу та змісту таких документів.
2.11. У розділі «Джерела розробки» мають бути перелічені документи та інформаційні матеріали, на підставі яких розроблялося ТЗ та які мають бути використані під час створення системи.

3. ПРАВИЛА ОФОРМЛЕННЯ

3.1. Розділи та підрозділи ТЗ повинні бути розміщені у порядку, встановленому у розд. 2 цього стандарту.

3.2. Номери аркушів (сторінок) проставляють, починаючи з першого аркуша, наступного за титульним аркушем, у верхній частині аркуша (над текстом, посередині) після позначення коду ТЗ на ІВ.

3.3. На титульному аркуші розміщують підписи замовника, розробника та узгоджувальних компаній, які скріплюють печаткою. За потреби титульний лист оформляють на кількох сторінках. Підписи розробників ТЗ і посадових осіб, що у погодженні та розгляді проекту ТЗ на ІВ, поміщають останньому листе.

Форму титульного листа ТЗ наведено у додатку 2. Форму останнього листа ТЗ наведено у додатку 3.

3.4. Титульний лист доповнення до ТЗ оформляють аналогічно до титульного листа технічного завдання. Замість найменування «Технічне завдання» пишуть «Додаток №… до ТЗ на AC…».

3.5. На наступних аркушах доповнення до ТЗ поміщають основу зміни, зміст зміни та посилання документи, відповідно до якими вносяться ці зміни.

3.8. При викладанні тексту доповнення до ТЗ слід зазначати номери відповідних пунктів, підпунктів, таблиць основного ТЗ тощо та застосовувати слова: «замінити», «доповнити», «виключити», «викласти у новій редакції».

ПОРЯДОК РОЗРОБКИ, УГОДИ І ЗАТВЕРДЖЕННЯ ТЗ НА ІС

1. Проект ТЗ розробляє організація-розробник системи за участю замовника на підставі технічних вимог (заявки, тактико-технічного завдання тощо).

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

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

Роботу за погодженням проекту ТЗ на ІС здійснюють спільно розробник ТЗ та замовник системи, кожен в організаціях свого міністерства (відомства).

3. Строк погодження проекту ТЗ у кожній організації не повинен перевищувати 15 днів з дня його отримання. Рекомендується розсилати на узгодження екземпляри проекту ТЗ (копій) одночасно у всі організації (підрозділи).

4. Зауваження щодо проекту ТЗ мають бути подані з технічним обґрунтуванням. Рішення щодо зауважень мають бути прийняті розробником проекту ТЗ та замовником системи до затвердження ТЗ на ІВ.

5. Якщо за погодженням проекту ТЗ виникли розбіжності між розробником та замовником (або іншими зацікавленими організаціями), то складається протокол розбіжностей (форма довільна) та конкретне рішення приймається в установленому порядку.

6. Узгодження проекту ТЗ дозволяється оформляти окремим документом (листом). У цьому випадку під грифом «Узгоджено» посилаються на цей документ.

7. Затвердження ТЗ здійснюють керівники компаній розробника та замовника системи.

8. Копії, затвердженого ТЗ у 10-денний строк після затвердження, надсилаються розробником ТЗ учасникам створення системи.

9. Погодження та затвердження доповнень до ТЗ проводять у порядку, встановленому для ТЗ на ІС.

10. Зміни до ТЗ не допускається затверджувати після подання системи або її черги на приймально-здавальні випробування.

ФОРМА ТИТУЛЬНОГО ЛИСТА ТЗ


______________________________________________________ .

найменування організації - розробника ТЗ на ІВ


СТВЕРДЖУЮ

Керівник (посада, найменування компанії – замовника ІВ)

печатка


Дата
СТВЕРДЖУЮ

Керівник (посада, найменування компанії - розробник" ІВ)

Особистий підпис Розшифровка підпису

печатка


Дата

найменування виду ІВ

________________________________________________________

найменування об'єкта інформатизації

________________________________________________________

скорочене найменування ІВ
ТЕХНІЧНЕ ЗАВДАННЯ

На ____ аркушах


Діє з

ПОГОДЖЕНО


Керівник (посада, найменування узгоджувальної організації)

Особистий підпис Розшифровка підпису