Техзавдання на автоматизацію. Що таке технічне завдання? Положення щодо створення єдиного комплексу стандартів автоматизованих систем

129kb.09.12.2011 03:33

1.doc

^ Дата введенняз 01.01.1990р.

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

Рекомендований порядок розроблення, погодження та затвердження ТЗ на АС наведено у додатку 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. У підрозділі «Вимоги до системи загалом» вказують:

• 
  вимоги до структури та функціонування системи;
• 
  вимоги до чисельності та кваліфікації персоналу системи та режиму його роботи;
• 
  показники призначення;
• 
  вимоги до надійності;
• 
  вимоги безпеки;
• 
  вимоги до ергономіки та технічної естетики;
• 
  вимоги до транспортабельності для рухомих АС;
• 
  вимоги до експлуатації, технічного обслуговування, ремонту та зберігання компонентів системи;
• 
  вимоги щодо захисту інформації від несанкціонованого доступу;
• 
  вимоги щодо збереження інформації при аваріях;
• 
  вимоги щодо захисту від впливу зовнішніх впливів;
• 
  вимоги до патентної чистоти;
• 
  вимоги щодо стандартизації та уніфікації;
• 
  Додаткові вимоги.

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. До вимог до експлуатації, технічного обслуговування, ремонту та зберігання включають:

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

2.6.9. До вимог захисту інформації від несанкціонованого доступу включають вимоги, встановлені в НТД, що діє в галузі (відомстві) замовника.

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

2.6.1.11. У вимогах до засобів захисту від зовнішніх впливів наводять:

• 
  1) вимоги до радіоелектронного захисту засобів АС;
• 
  2) вимоги щодо стійкості, стійкості та міцності до зовнішніх впливів (середовищу застосування).

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

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

2.6.1.14. Додаткові вимоги включають:

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

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

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

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

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

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

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

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

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

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

• 
  1) до складу, структури та способів організації даних у системі;
• 
  2) до інформаційного обміну між компонентами системи;
• 
  3) до інформаційної сумісності із суміжними системами;
• 
  4) щодо використання загальносоюзних та зареєстрованих республіканських, галузевих класифікаторів, уніфікованих документів та класифікаторів, що діють на даному підприємстві;
• 
  5) щодо застосування систем управління базами даних;
• 
  6) до структури процесу збору, обробки, передачі даних у системі та подання даних;
• 
  7) до захисту даних від руйнувань при аваріях та збоях в електроживленні системи;
• 
  8) до контролю, зберігання, оновлення та відновлення даних;
• 
  9) до процедури надання юридичної сили документам, що продукуються технічними засобами АС (відповідно до ГОСТ 6.10.4 ).

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

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

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

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

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

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

• 
  1) попередній перелік вимірювальних каналів;
• 
  2) вимоги до точності вимірювань параметрів та (або) до метрологічних характеристик вимірювальних каналів;
• 
  3) вимоги до метрологічної сумісності технічних засобів;
• 
  4) перелік управляючих та обчислювальних каналів системи, для яких необхідно оцінювати точнісні характеристики;
• 
  5) вимоги до метрологічного забезпечення технічних та програмних засобів, що входять до складу вимірювальних каналів системи, засобів, вбудованого контролю, метрологічної придатності вимірювальних каналів та засобів вимірювань, що використовуються при налагодженні та випробуваннях системи;
• 
  6) вид метрологічної атестації (державна чи відомча) із зазначенням порядку її виконання та організацій, які проводять атестацію.

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

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

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

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

2.6.3.8. Для методичного забезпечення САПР наводять вимоги до складу нормативно-технічної документації системи (перелік застосовуваних під час її функціонування стандартів, нормативів, методик тощо).

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

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

• 
  1) перелік документів, за ГОСТ 34.201-89 , що пред'являються після закінчення відповідних стадій та етапів робіт;
• 
  2) вид та порядок проведення експертизи технічної документації (стадія, етап, обсяг документації, що перевіряється, організація-експерт);
• 
  3) програму робіт, спрямованих на забезпечення необхідного рівня надійності системи, що розробляється (при необхідності);
• 
  4) перелік робіт з метрологічного забезпечення на всіх стадіях створення системи із зазначенням їх термінів виконання та організацій-виконавців (при необхідності).

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

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

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

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

• 
  1) приведення інформації, що надходить до системи (відповідно до вимог до інформаційного та лінгвістичного забезпечення) до виду, придатного для обробки за допомогою ЕОМ;
• 
  2) зміни, які необхідно здійснити в об'єкті автоматизації;
• 
  3) створення умов функціонування об'єкта автоматизації, у яких гарантується відповідність створюваної системи вимогам, які у ТЗ;
• 
  4) створення необхідних для функціонування системи підрозділів та служб;
• 
  5) терміни та порядок комплектування штатів та навчання персоналу.

Наприклад, для АСУ наводять:

• 
  зміни застосовуваних методів управління;
• 
  створення умов роботи компонентів АСУ, у яких гарантується відповідність системи вимогам, які у ТЗ.

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

• 
  1) узгоджений розробником та Замовником системи перелік комплектів та видів документів, що підлягають розробці, відповідних вимогам ГОСТ 34.201-89 та НТД галузі замовника;
  перелік документів, що випускаються на машинних носіях;
  вимоги до мікрофільмування документації;
• 
  2) вимоги щодо документування комплектуючих елементів міжгалузевого застосування відповідно до вимог ЄСКД та ЕСПД;
• 
  3) за відсутності державних стандартів, що визначають вимоги до документування елементів системи, додатково включають вимоги до складу та змісту таких документів.

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

2.12. До складу ТЗ на АС за наявності затверджених методик включають додатки, що містять:

• 
  1) розрахунок очікуваної ефективності системи;
• 
  2) оцінку науково-технічного рівня системи.

Програми включають до складу ТЗ на АС за погодженням між розробником та замовником системи.
^

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.

______________________________________________________ Найменування організації – розробника ТЗ на АС СТВЕРДЖУЮ Керівник (посада, найменування підприємства – замовника АС) Дата СТВЕРДЖУЮ Керівник (посада, найменування підприємства - розробник "АС") Особистий підпис Розшифровка підпису Найменування виду АС ________________________________________________________ Найменування об'єкта автоматизації ________________________________________________________ Скорочене найменування АС ^ ТЕХНІЧНЕ ЗАВДАННЯ На ____ аркушах Діє з ПОГОДЖЕНО Керівник (посада, найменування узгоджувальної організації) Особистий підпис Розшифровка підпису

Склали

ПОГОДЖЕНО

ДОДАТОК 4
Довідкове
^

ПОЛОЖЕННЯ З СТВОРЕННЯ ЄДИНОГО КОМПЛЕКСУ СТАНДАРТІВ АВТОМАТИЗОВАНИХ СИСТЕМ

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. Взаємозв'язок ЕКС АС з іншими системами та комплексами стандартів

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. Програмно-технічні та програмно-методичні комплекси розглядаються як складні вироби, які не мають аналогів у машинобудуванні. Враховуючи статус ПТК та ПМК як продукції виробничо-технічного призначення, правила та порядок їх розробки має бути аналогічним вимогам, встановленим стандартами системи розробки та постановки продукції на виробництво (СРПП).

Добре подумавши, я вирішив, що вмістити весь матеріал планованої другої частини в одну статтю знову не вийде, інакше це буде верхи і теоретично, що й так написано в багатьох підручниках. Але ж я ставлю завдання, щоб це можна було застосовувати на практиці, тому не буду більше загадувати на майбутнє про те, скільки випусків ще потрібно, щоб закінчити з темою. На це впливатиме і зворотний зв'язок із читачами, тож пишіть, не соромтеся!

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

Оскільки читачами є не лише фахівці в галузі розробки програмного забезпечення, а також бізнес-аналітики та керівники різного рівня, Постараюсь писати так, щоб було цікаво всім.

У цій частині ми будемо говорити про те, як організувати етап робіт зі збирання вимог, з чого він має складатися та якими інструментами можна користуватися. Повторюся, що ці роботи з погляду етапів дуже схожі на обстеження підприємства з метою опису бізнес-процесів.

Як зазвичай відбувається у житті:

Як це відбувається у більшості проектів
Кроки	Як це відбувається
	Зрозуміло, що є привід для радості, особливо, якщо проект великий, нічого поганого в цьому немає! Головне, не радіти надто довго, відтягуючи початок фактичних робіт, із цієї хвилини час йтиме інакше.
	Зазвичай цей процес обмежується кількома зустрічами з керівництвом, потім із керівниками підрозділів. Зафіксувавши деякі «позиви» із боку Замовника, вони фіксуються як загальних формулювань. Іноді до цього додають наявну документацію (хтось колись намагався вже поводити обстеження, документи з існуючих регламентів, форми звітів, що використовуються) Як не дивно, але після цього більшість впроваджених систем автоматизації радісно вигукує: «та в нашій системі все це є! Ну, трохи налаштувати і все буде працювати». На питання, чи треба обговорювати, як усе має працювати (або як виконується конкретний процес) з кінцевими користувачами, відповідь зазвичай негативна. Висловлюється думка, що керівник усе знає про своїх підлеглих. А дарма ... За цим ховається безліч пасток і перешкод, і здавання робіт може перетворитися на марафон смужкою з перешкодами. Як відомо, марафон прийнято бігати рівною дорогою, а біг з перешкодами можливий лише на коротких дистанціях (можна і не добігти).
Документування результатів роботи	Після цього починається документування результатів залежно від цілей робіт: Якщо потрібно розробити Технічне завдання , консультант починає розсовувати отриману інформацію за заготовленим шаблоном документа, щоб і виглядало красиво, і основні вимоги були зафіксовані (ті, що озвучені від керівництва, а то можуть не затвердити). Розуміючи, що на практиці таке Технічне завдання особливо не використовується і доводиться все з'ясовувати "по ходу справи", головною метою Технічного завдання він ставить мінімальний час узгодження та затвердження. І, якщо вийде, інформація для зразкової оцінки вартості майбутніх робіт (до речі, теж важливо). Якщо потрібно описати бізнес-процеси. Як не дивно, але часто всі попередні дії виглядають аналогічно, як і у випадку розробки Технічного завдання. Різниця лише в оформленні документації. Тут можливі варіанти: консультанти описують процес довільними словами або використовують правила опису бізнес-процесів (нотації). У першому випадку такий документ виходить дивовижно схожим на Технічне завдання. Буває навіть таке, що якщо замінити титульний лист, жодної різниці не побачиш. В останньому випадку часто наголошують не на відповідності дійсності, а на «правильності опису», тобто. формальне дотримання правил опису. На жаль, обидва варіанти є не самою найкращою практикою, т.к. є скоріше формальністю, а користі приносять небагато.

Чому склалася така практика, як описано вище? Зізнаюся, я не знаю. У кого не спитай, ніхто не знає. При цьому ситуація змінюється не дуже швидко, хоча на цю тему постійно дискутують, обмінюються досвідом, пишуть книги… Мені здається, що одна з причин – низька якість відповідної освіти. Може ще позначається і те що, що багато фахівців приходить взагалі їх іншого бізнесу, і осягають все практично, тобто. їх досвід формується у тому середовищі, куди вони потрапили. Про ставлення ВНЗ та відсутність їхнього прагнення бути ближчим до реальності, теж факт відомий, але мене іноді дивує їхня позиція. Наприклад, у мене був випадок, коли дипломниця, талановитий фахівець, хотіла писати дипломну роботу на платформі 1С (хорошу галузеву розробку), але на кафедрі їй сказали, що незалежно від теми, на оцінку «відмінно» розраховувати не можна буде, т.к. 1С несерйозна система. Тут справа не в серйозності та об'єктивності такої думки, а в тому, що примітивне завдання класичною мовою програмування відразу вважалося гідним оцінки «відмінно».

Спробуємо надати розглянутому вище процесу більш системний підхід. Як він може виглядати тоді?

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

Хочу особливо наголосити, що до останнього кроку на схемі (там, де питання) загальний принцип збору інформації про діяльність компанії виглядає однаково, незалежно від того, що планується робити надалі, описувати бізнес-процеси чи впроваджувати автоматизовану систему. Так, сама послідовність кроків однакова, але інструменти, які застосовуються на деяких з них, можуть відрізнятися. Ми зараз обов'язково розглянемо, коли вивчатимемо методики та інструменти окремих етапів. Докладно це робитимемо в окремих статтях, а зараз розглянемо тільки найголовніше. Подальші кроки відрізнятимуться і визначатиметься тим, що потрібно від проекту: описати бізнес-процеси чи впроваджувати систему обліку.

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

Як це може відбуватися за більш грамотної організації робіт
Кроки	Як це відбувається
Рішення прийнято, проекту бути!	Тут нічого не змінюється щодо першого варіанта, емоції ніхто не скасовував
Провели нараду з керівниками, зібрали деяку інформацію про їхнє бачення результату.	Цей крок також залишається, і він має велике значення. Але основне призначення першої зустрічі (або кількох зустрічей) із керівниками та власниками це знайомство. Знайомство насамперед із людьми та компанією. Сформульовані цілі та побажання на таких спільних зустрічах можуть бути різними, у тому числі фантастичними. Всі вони будуть, звичайно ж, вислухані, але не факт, що їх буде реалізовано. При глибшому зануренні в бізнес компанії будуть з'являтися інші цілі, так і відкидатися попередні. Я це до того, що з попередніх зустрічей не можна сформулювати чіткі цілі, все це потребуватиме ретельного опрацювання. Навіть просте здавалося б вимога може бути нереалізованим чи дуже трудомістким.
Формування робочої групи від Замовника та Виконавця, розподіл ролей	Необхідно визначитися, хто працюватиме над проектом як з боку Замовника, так і Виконавця. Незважаючи на простоту даного етапу, він має дуже велику роль. Якщо не зафіксувати чітко, хто за що відповідає, під час реалізації робіт Ви ризикуєте зіткнутися з плутаниною. Якщо зі свого боку Ви завжди можете конкретизувати ролі у своїй команді, то у Замовника з цим можуть виникнути проблеми. На що слід звернути увагу: до складу робочої групи Замовника обов'язково мають увійти ті люди, які надалі хоч якось впливатимуть на прийняття результату. Якщо припустити ситуацію, що під час здачі робіт підключаться співробітники Замовника, які не брали участі у роботах з формування цілей та виявлення вимог, то проблеми гарантовані. Можлива навіть така абсурдна ситуація, що все, виявляється, зроблено не так, як вимагалося. У моїй практиці я стикався з такою ситуацією не раз. ніхто, крім робочої групи Замовника, не може брати участь у прийманні-здачі робіт. А найкраще прописати таке в договірних умовах (У договорі або Статуті проекту). Пам'ятаю, був такий випадок: в одному великому проекті засновник вирішив підключитися до процесу (не знаю чому, нудно бачити стало) і відвідав одну з робочих зустрічей, де обговорювалося питання формування рахунків клієнтам. Він із подивом для себе дізнався, що рахунок клієнту виставляє менеджер із продажу. У його поданні рахунок має виставляти бухгалтер і ніяк інакше. Але насправді бухгалтер взагалі не уявляв, про що йдеться, а менеджер не міг уявити, як так працювати, якщо за кожним рахунком бігати до бухгалтера. В результаті втратили купу часу, але нічого не змінилося, рахунок, як і раніше, виставляв менеджер. А засновник залишився на своїй думці, але більше в процес не втручався. На цьому етапі доцільно розробити Статут проекту, у якому зафіксувати ролі учасників, порядок комунікацій, регламент та склад звітності, а також все інше, що слід прописати у Статуті. Розробка Статуту проекту це тема знову ж таки окрема.
Навчання проектної команди методикам та інструментам роботи, узгодження правил роботи, видів та складу документації	По-перше, необхідно роз'яснити проектній команді все, що прописано у Статуті, як це застосовуватиметься на практиці. По-друге, проектну команду Замовника необхідно навчити тим методам роботи, які Ви збираєтеся використати на всіх наступних етапах. Має сенс обговорити формати документів, які будуть використовуватись, розглянути зразки. Якщо будуть застосовуватися будь-які правила опису моделей або бізнес-процесів, то треба обговорити і ці правила, щоб вони були зрозумілими.
Анкетування	Етап анкетування дозволяє порівняно швидким способом отримати достовірний зріз інформації про компанію. Якість такої інформації визначатиметься трьома факторами: Насамперед тим, як Ви навчили проектну групу Замовника. Вони повинні чітко розуміти, як відбувається процес анкетування та вміти донести інформацію до всіх учасників. Сама форма анкет. Анкети мають бути зрозумілими. Бажано, щоб була інструкція із заповнення анкет. Ще краще, якщо буде приклад наповнення. Склад учасників. Необхідно правильно вибрати склад учасників. Якщо обмежитись лише керівниками, зібрати достовірну інформацію не вдасться. Я рекомендую включати до складу анкетування всіх, хто буде в майбутньому користувачем кінцевих результатів. Наприклад, якщо йдеться про впровадження автоматизованої системи, то варто включити всіх, хто буде користувачем. Бувають випадки, коли з 10 співробітників однієї посади знайдеться один, який виконує якусь особливу функцію, про яку ніхто з 9-ти більше не знає (наприклад, готує особливий звіт для керівництва). Якщо йдеться про подальший перерозподіл обов'язків або розробку посадових інструкцій, слід зробити аналогічно. Звертаю увагу, що методика анкетування для подальшого впровадження автоматизованої системи або опис бізнес-процесів у правильному випадку відрізняється. Звичайно, структура анкет може бути і однакова, але це не найкращий варіант. Коли ми описуємо бізнес-процеси, то анкети зазвичай мають загальніший характер, т.к. невідомо точно, із чим доведеться зіткнутися. Якщо ж йдеться про впровадження конкретної автоматизованої системи, то краще мати анкети, що враховують особливості цієї системи. При такому підході можна відразу виявити всі вузькі місця системи, які не підходять для цього підприємства. Як правило, методики впровадження готових систем передбачають наявність таких анкет. Такі анкети можуть розроблятися або за окремими областями обліку (наприклад, облік замовлень, продажу, ціноутворення) або для конкретних посад (фінансового директора, наприклад). Склад питань приблизно однаковий.
Опитування	Опитуванням називається проведення усної співбесіди з фахівцями з метою з'ясувати особливості окремих процесів. Необхідно організувати опитування так, щоб воно не виглядало як просто «зустрілися-поговорили», а організовано. Для цього потрібно підготувати так званий план опитування. До нього можна включити ті частини анкети, які викликають питання, суперечать відомостям інших анкет чи інформація представлена ​​поверхнево. Відповіді треба конспектувати в обов'язковому порядку. Ідеально, якщо Ви домовитеся про аудіозапис. На цьому етапі слід простежити за повнотою наданої інформації про документообіг (як форм первинних документів, так і різних звітів)
Виділення ключових бізнес-процесів або областей автоматизації	Після анкетування та опитування можна обґрунтовано вважати, що інформації достатньо, щоб робити висновки щодо виділення ключових бізнес-процесів. Насправді, вже можна виділити не лише ключові бізнес-процеси, а й практично всі (якщо склад учасників було обрано правильно). Питання виділення бізнес-процесів це тема дуже окрема і не проста. Навчитися тут складно і виробляється переважно досвідом. З виділених бізнес-процесів слід скласти список (класифікатор). Потім можна буде приймати рішення, які з них слід досліджувати глибше, які ні, а також виділяти пріоритети.
Формулювання ключових вимог до системи, цілей, критеріїв успішності проекту, процесів для детального вивчення	До цього етапу має бути зібрана вся первинна інформація про діяльність компанії, складено перелік бізнес-процесів. Тепер саме час повернутися до цілей, конкретизувати їх, за необхідності обговорити з першими особами компанії. При формулюванні цілей слід врахувати конкретні показники, при досягненні яких вважатимемо проект успішним. Якщо йдеться про впровадження автоматизованої системи, окремим переліком можна виділити вимоги до системи від ключових користувачів. Я це роблю у вигляді окремої таблиці, де всі вимоги згруповані за підсистемами, для кожної вимоги вказується автор вимоги, формулювання та пріоритет. Цю інформацію можна буде використовувати для складання плану розгортання системи (послідовності впровадження окремих підсистем), а також пропозицій щодо подальшого розвитку системи (якщо окремі підсистеми в поточному проекті впроваджувати не планується). Якщо необхідно описати бізнес-процеси, приймаються рішення про процеси, які необхідно досліджувати більш детально.

От і дісталися питання «Що далі?». Далі розглядатимемо завдання опису бізнес-процесів та розробки Технічного завдання окремо. Я невипадково розглядаю ці завдання паралельно. Між ними справді багато спільного, що я хочу продемонструвати. Спочатку розглянемо послідовність робіт під час опису бізнес-процесів.

Кроки	Що і як робити
Виділяємо бізнес-процес	Із загального переліку бізнес-процесів, отриманого на попередніх етапах, виділяємо один (за пріоритетом) для детального опрацювання. З рештою потім чинимо аналогічно.
Детальне вивчення бізнес-процесу	Виділений бізнес-процес піддаємо детальному вивченню: аналізуємо отримані первинні документи, звіти та їх структуру, що використовуються в процесі програми, різні файли (наприклад, Excel), розмовляємо з кінцевими виконавцями. Збираємо різні ідеї про те, як можна покращити процес. Дуже корисно, якщо вдасться поспостерігати за процесом саме в тих умовах, в яких він виконується (не багато хто любить, коли за ними спостерігає, але що робити)
Графічний та/або текстовий опис бізнес-процесу (первинний)	Отриману докладну інформацію починаємо описувати. Перш ніж описувати процес, треба визначитися, чи вимагатиме він графічного опису. Якщо процес простий і зрозумілий, функцій у ньому мало, і, графічне уявленняне покращить його розуміння чи сприйняття, то не треба витрачати на цей час. І тут досить описати їх у текстовому вигляді у табличній формі. Якщо ж процес складний, з різними логічними умовами, краще навести його графічну схему. Діаграми завжди сприймаються легше. Якщо Ви вирішили описати процес у графічному вигляді, це зовсім не означає, що не треба наводити його текстовий опис. Тобто. текстовий опис процесу має бути у будь-якому випадку, причому виконаний за однаковою схемою. Зручно це робити у вигляді таблиці, де вказати: виконавців кожного кроку, яку інформацію вони отримують на вході, опис кожного кроку, яку інформацію формують на виході. Нижче подивимося на прикладі, як це може виглядати.
Погодження з виконавцями та власником бізнес-процесу	Кращий спосіб зрозуміти, наскільки вдало ви вибрали стиль викладу інформації, це показати результат користувачам (виконавцям) процесу. На найголовніше в такій демонстрації це розуміння того, наскільки правильно Ви зрозуміли, як процес виконується. від виконавців цілком адекватного зворотного зв'язку. А якщо їм стане цікаво, то просуватися все почне набагато швидше. Виявлені уточнення та невідповідності необхідно відобразити в описі (актуалізувати), за необхідності операцію повторити.
Виділення показників бізнес-процесу	Після того, як вироблено правильне розуміння, як виконується бізнес-процес, треба подумати над показниками, якими можна виміряти якість чи швидкість виконання процесу. Це не просто, але потрібно. Показник може бути вимірюваним, тобто. виражений у числовому вираженні і має існувати простий спосіб цю величину отримати. Якщо показник, що вимірюється, виділити неможливо, є ризик того, що бізнес-процес виділено невдало. Крім того, не буде можливості зрозуміти (адже виміряти не можна), приведуть зміни процесу до його поліпшення чи ні.
Остаточне документування бізнес-процесу	Після того, як ми переконалися у правильному розумінні, як процес виконується (або має виконуватися), можна включати його до документації.
	Далі можливі варіанти: аналізовані процеси будуть аналізуватися та оптимізуватися, розроблятися посадові інструкції, приймати рішення про необхідність автоматизації окремих процесів і т.д. Це може бути і окремий проект: опис бізнес-процесів.

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

Кроки	Що і як робити
Виділяємо бізнес-вимогу/область автоматизації	Виділення як вимоги цілої області автоматизації (наприклад, «Складські запаси») на практиці використовується, однак, це не самий ефективний спосібдеталізації вимог. Область автоматизації є групою вимог, і розглядати їх краще за кожне окремо. Наприклад, «Облік надходження матеріалу на склад»
Детальне вивчення бізнес-вимоги	Під детальним вивченням бізнес-вимоги розуміється те, як це хоче бачити і використовуватиме кінцевий користувач (зрозуміло, відповідно до цілей проекту). У технологіях розробки програмного забезпечення часто називають «варіант використання». Таким чином, детальне вивчення бізнес-вимоги зводиться до опрацювання варіантів використання. Приклад такого варіанту наведено у додатку 2 до статті. У найпростіших випадках варіанти використання зовсім не обов'язково малювати у вигляді графічних схем, можна обмежитися і текстовим формулюванням. Наприклад, вимога «Під час введення номенклатури ціна має розрахуватися як ціна закупівлі +20%» малювати не має сенсу. У вигляді діаграми є сенс представляти вимоги, об'єднані в область автоматизації, як показано в прикладі в додатку 2.
Моделювання вимог в інформаційній системі	Ось воно! Як Ви, напевно, пам'ятаєте, я вже звертав увагу на цей найважливіший елемент у методиці розробки Технічних завдань. «Побудуй модель – отримаєш результат!» А що треба моделювати? Моделювати треба варіанти використання, отримані на попередньому етапі. Що має бути на виході моделювання? Повинна вийти демонстраційна програма, в яку внесені дані користувача, причому бажано звичні його (користувача) слуху, з урахуванням галузевої специфіки, актуальних проблем. І не просто так внесено, а має бути зрозуміло, звідки ці дані взялися, як розрахувалися. У цьому місці у читача мають виникнути питання: А що, якщо планується розробка нової системи і моделювати просто нема в чому? Що якщо для демонстрації не вистачає функціональності, і систему треба доопрацьовувати? Звичайно, Ви маєте зіткнутися з такою ситуацією, і це нормально. Що робити? Якщо система зовсім нова (як то кажуть «з нуля»), то моделювати доведеться здебільшого на папері, тут Вам діаграми варіантів використання дуже допоможуть. Частково має сенс накидати деякі екранні форми, які передбачається розробити (у тому середовищі, у якій вестиметься розробка), т.к. малювати їх у якомусь редакторі буде довше і ця робота нудна. Якщо впроваджується готова система, і в ній не вистачає функціональності, то нічого страшного немає, дані вносяться руками, а користувачеві так і розповідається, що після необхідних доробок має розрахуватися так і так (і він це бачить). Доцільно супроводити таку модель текстовим описом, нехай навіть стислим, щоб користувач міг самостійно спробувати попрацювати з моделлю у вільний час. У цьому описі можна формулювати вимоги до доработок.
Демонстрація інформаційної моделі робочої групи	Отриману модель показуємо Замовнику і розповідаємо, як усе має працювати. Демонстрацію моделі краще проводити підсистемами, тобто. за групами вимог. У випадку, якщо з'ясується, що у клієнта пропонована схема не працюватиме, треба подумати про інші варіанти використання, внести зміни в модель і показати ще раз. Тільки якщо є впевненість, що запланована модель у даного клієнта «житиме», можна вважати модель вдалою.
Розробка тестів	Для чого потрібні тести? Те, як ми змогли реалізувати вимоги, потрібно перевіряти. Відповідно, на всі ключові ділянки, складні алгоритми та ін тести бажано зробити. У тому числі, ці тести можуть бути використані при здачі робіт. Зовсім необов'язково робити тести на кожну функцію системи, скрізь має бути здоровий глузд. Якщо йдеться про готову систему, то робити тест на «введення нового елемента до довідника клієнтів» буде виглядати безглуздо і марною тратою сил і часу. А якщо це зовсім нова система, таке цілком можливо. Навіщо робити тести, якщо ще немає системи? По-перше, розробнику буде зрозуміліше, чого від нього хочуть досягти. По-друге, ми полегшуємо життя тестувальнику (адже хтось тестуватиме результат розробки). Взагалі, тестування це окрема дисципліна, вельми не проста з безліччю методик. Насправді, зазвичай, однаково використовуються найпростіші методи тестування.
Документування вимог у вигляді Технічного завдання	Зібрана інформація на попередніх етапах буде саме тим, що й має увійти в основу документа «Технічне завдання» у розділі з вимогами. Тож залишається все це грамотно оформити.
Подальші дії (або їх відсутність), залежно від цілей проекту	Далі може початися процес розробки, пошук партнерів для проекту, тендер тощо, все залежить від ситуації.

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

Додаток 1. Описаний бізнес-процес у нотації EPC.