3.4. ХАРАКТЕРИСТИКА СУЧАСНИХ ЗАСОБІВ АВТОМАТИЗОВАНОГО КЕРУВАННЯ ВИМОГАМИ

Нині існує три основні типи систем керування вимогами:

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

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

3) програмні платформи, що забезпечують автоматизоване керування життєвим циклом ІС, зокрема, управління вимогами, з кількома репозиторіями. У цьому варіанті існують єдині сервіси для кожного із засобів.

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

1) Збирання (ідентифікація) вимог:

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

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

— інтерактивна (напівавтоматична) ідентифікація вимог — ідентифікація вимог на основі дій користувача, наприклад, після виділення користувачем тексту і ствердної відповіді на запитання системи «Це вимога?»;

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

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

— класифікація вимог;

— автоматична ідентифікація вимог та присвоєння числових або змішаних кодів.

Вимоги можуть вводитися в систему вручну або імпортуватися з таблиць чи текстових документів. Найпоширеніші формати для розпізнавання — ASCII, Rich Text Format (RTF), CSV, документи Microsoft Word, таблиці Microsoft Excel, XRI . Імпорт відбувається за результатами аналізу форматованого чи розмежованого тексту за структурою, ключовими словами/фразами, унікальними ідентифікаторами або стилем оформлення (номерами параграфів і заголовками) в автоматичному або напівавтоматичному режимі. Наприклад, система Optimal Trace пропонує функцію «знайти схоже» для виділеної ділянки тексту — будьякий шрифт або стиль документа може бути інтерпретований і розпізнаний.

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

Система Envision VIP містить об’єктноорієнтований репозиторій, у якому знаходить місце кожна частина документа. Вимоги розглядаються як об’єкти: прості або складні. Можна відстежити також ключові слова, фрази і навіть більш примітивні об’єкти. Такий підхід дає можливість будувати ефективну звітність — формувати індекси, глосарії, документи MS Word, таблиці MS Excel тощо. У тексті використовуються посилання на певні об’єкти, через ці посилання можна отримати доступ до відповідних вимог. У разі зміни назви об’єкта або його атрибутів у репозиторії змінюється і звіт.

Optimal Trace Enterprise зберігає дані у форматі реляційної бази даних (SQLсумісної) з підтримкою MySQL, MS SQL Server та Oracle 9i. У режимі оффлайн (за відсутності зв’язку з репозиторієм) вимоги записуються у форматі XML. Відкритість цих форматів та їх використання як галузевих стандартів забезпечує переваги цього підходу, зокрема під час формування специфічних звітних документів із застосуванням інших систем.

Деякі засоби (CASE Spec) захоплюють вимоги з прецедентів. У деяких системах припускається, що імпортовані вимоги можуть містити таблиці, наукові формули та графіку.

Під час імпорту системи можуть надавати такі можливості:

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

— елемент записується в базу даних за будьяких умов. Якщо він був імпортований раніше, інформація перезаписується;

— при імпорті відбувається операція злиття — елемент імпортується незалежно від його наявності у базі даних, але до бази записуються лише нові вимоги та їх атрибути, а також атрибути, які слід оновити. Така можливість є корисною при використанні численних джерел інформації. Наприклад, ієрархію вимог можна імпортувати з документа Microsoft Word, а атрибути цих вимог — з таблиці Microsoft Excel. Інший варіант — формується кілька версій вимог.

Після завершення імпорту користувач дістає можливість створювати додаткові вимоги чи редагувати наявні елементи вручну або автоматично (на основі скриптів).

Додатковою можливістю (Compuware Optimal Trace) є організація робочих сесій аналітика з усіма зацікавленими особами за допомогою засобів телекомунікацій з одночасним формуванням файлів у форматі MS Word і публікацією документів зі сформованими вимогами. Колективне обговорення створює передумови для формулювання коректних, послідовних, повних, узгоджених і придатних для перевірки вимог кожним учасником дискусії, а онлайн режим роботи забезпечує вчасне ознайомлення з остаточним варіантом документа і внесення коректив, що зменшує кількість помилок і надмірність. Таким чином знімається необхідність ручного формування вимог, які згодом імпортуватимуться в систему керування вимогами.

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

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

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

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

2) Визначення структури системи:

— графічне подання структури системи;

— текстове подання структури системи.

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

Найчастіше забезпечується підтримка методологій UML, структурного або об’єктноорієнтованого аналізу. Цей перелік можна розширювати. Наприклад, набір моделей, що пропонується системою CORE, включає діаграми IDEF0, DFD, FFBD (functional flow block diagram, структурна схема функціональних потоків), eFFBDs (expanded functional flow block diagram, розширювана структурна схема функціональних потоків), PBD (physical block diagram, фізична структурна схема), ієрархії, а також таблиці інтерфейсу (interface chart, N2). Enterprise Architect, крім UML, підтримує BPMN, SysML та Requirements modeling.

Система PTESY надає можливість визначати структурні об’єкти численних типів, серед яких підсистеми, компоненти, робочі модулі, методи верифікації, типи тестів, типи вимог тощо. Підсистеми і компоненти структуруються каскадом зі зв’язками «батько—дитина». Кожен об’єкт методології (вимоги, тестові процедури, контрольні приклади, проблеми, події тощо) може бути присвоєний одній або багатьом підсистемам або компонентам. Також передбачено можливість встановлення посилкових зв’язків між об’єктами, наприклад між вимогами та іншими вимогами, проблемами, контрольними прикладами, подіями, документами та/або сигналами тощо.

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

Якщо не було застосовано конкретної методології моделювання, користувач може організувати віртуальну бібліотеку з «книгами» і «книжковими полицями» або «пакетами» і «папками». Наприклад, система Optimal Trace має функцію уточнення вимог — вимога верхнього рівня деталізується на нижчих рівнях. Результати такої декомпозиції подаються у графічному вигляді. Елементи найнижчого рівня мають посилання на елементи системи.

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

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

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

3) Диференціація вимог:

— виведення вимог — можливість виведення/створення додаткових вимог і встановлення зв’язків між ними типу «вимога— вимога», «вимога—текст аналізу»;

— розподіл вимог (вага, ризик, вартість тощо) за елементами системи;

— встановлення двоспрямованих зв’язків між елементами системи та вимогами;

— додаткові відомості — обґрунтування розподілу вимог, відповідальність, власник/автор, перевірка, проблемні питання тощо.

Системи керування вимогами дають можливість встановлювати різноманітні категорії вимог і зв’язків між ними, зокрема «бізнесвимога — вимога користувача — функціональна вимога — специфікація» (Accept 360); бізнесвимоги і вимоги користувача з вкладеними папками вимог з високим та низьким пріоритетом (Kovair Global Lifecycle). У системі RaQuest вимоги розподіляються за складністю, пріоритетом, стабільністю та ризиком.

Accept 360 містить «ринкову модель», елементами якої є споживачі (реальні і перспективні), сегменти, теми, конкуренти, ризики. Кожна вимога має зважений зв’язок з названими елементами, а також з пропозиціями, дефектами, прецедентами. Спеціальний аналітичний модуль виконує пріоритетизацію вимог, виходячи з проставленої ваги.

Система Cockpit дозволяє встановлювати функціональні залежності у вигляді рівнянь для визначення поточного стану вимоги. Потужним механізмом є метрики (вартість, вага, MTTR тощо), які автоматично генеруються на вимогу користувача. Cockpit уміє розпізнавати метрики і виводити узагальнені значення для відстежування виконання вимоги. Наприклад, у разі встановлення вартості як окремої вимоги Cockpit розраховує підсумок.

У системі Cradle вимоги пов’язуються двоспрямованими, транзитивними перехресними посиланнями «багатодобагатьох», для яких встановлюються типи та атрибути з елементами структур WBS (Work Breakdown Structure, структура розбивки робіт), SBS (System Breakdown Structure, структура розбивки системи) або PBS (Product Breakdown Structure, структура розбивки продукту). Додаткова інформація може містити текст, таблиці, рівняння, відео або аудіозаписи, малюнки CAD/CAM тощо. Для полегшення візуального сприйняття інформації використовують кольорові позначення.

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

— традиційна ієрархія;

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

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

— зв’язки між вимогами — користувач може прямо встановити зв’язки між вручну вибраними вимогами і ввести інформацію щодо причин встановлення такого зв’язку.

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

Особливістю PTESY є наявність спеціального засобу керування інжинірингом тестів TestBook, за допомогою якого можна визначити процедури тестування, контрольні приклади і тестові кроки, а також скласти звіт про тестування під час виконання тестів. Кожен контрольний приклад має прив’язку до вимог, що він їх покриває. Матриці трасування можна генерувати із сортуванням за контрольними прикладами або вимогами. Також у складі системи є засоби EventsBook, який дає можливість фіксувати будьяку критичну або значущу для реалізації, перевірки тощо вимоги подію, та LogBook для запису та керування виявленими проблемами, зокрема під час виконання тестів. Кожна зареєстрована проблема може посилатись на одну або більше порушених вимог, контрольний приклад, який уможливив її виявлення, та інші об’єкти.

4) Аналіз зв’язків трасування:

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

— просування за зв’язками від джерела до реалізації;

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

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

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

Наприклад, у системі DOORS «сиротою» може бути об’єкт/ вимога, що не має жодного зв’язку, не має вхідних/вихідних зв’язків або зв’язків певного типу. Також можна накласти й інші умови, зокрема, показати всі тести без зв’язків, що їх не було виконано, або всі зв’язки до невдалих тестів. В Accept 360 «сиротами» вважаються вимоги, які не позначені до виконання у той час, коли їх «батьки» такі позначки мають. Cockpit має вбудовані функції виявлення елементів, які не мають зв’язків або не документовані. За допомогою численних опцій користувачі взмозі перевірити вимоги за ознаками дати/часу, схвалення, виконання числових вимог, схожістю до цілі через аналіз трендів тощо. В IRQA підозрілими вважаються зв’язки, в яких бодай одного із учасників було змінено і, відповідно, необхідно перевірити зв’язок, щоб уникнути суперечностей. Звіти про перевірку на несуперечність містять невизначені елементи, елементи без зв’язків, вимоги без асоційованих тестів. Передбачено також перевірку узгодженості структурних схем.

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

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

Концепція, реалізована в системі Cockpit, передбачає присвоєння числових величин з інтервалом і цільовим, і поточним (отриманим під час проектування, розроблення і тестування) значенням вимог. Також користувач може задавати статистичні функції для визначення поведінки вимог на підставі підпорядкованих вимог. При цьому можна використовувати як внутрішній калькулятор функції, так і можливості Excel, Crystal Ball, @Risk, Minitab, Enventive, Matlab. У Cockpit також передбачено можливості настроювання для інтеграції з іншими аналітичними засобами.

У системі Kovair Global Lifecycle можна встановлювати зв’язки «одиндоодного», «одиндобагатьох», «багатодобагатьох», одно та двосторонні між однаковими та різними сутностями. Таким чином можна побудувати зв’язки «вимоги — прецеденти — елементи проекту — контрольні приклади — результат», які дають можливість простежити повний ланцюжок від джерела до реалізації за допомогою ієрархічних текстових звітів або мережної діаграми. У системі також можна визначити процес, який створює численні завдання для різних користувачів певної вимоги у певний робочий період, у тому числі й паралельні. Вбудована система керування завданнями дає можливість відстежувати статус вимоги в той час, коли користувачі завершують свої завдання, і повну реалізацію після завершення всього процесу. На основі технології Kovair’s Omnibus до реалізації такого автоматизованого процесу можуть бути залучені засоби сторонніх фірм і створена повна мережа артефактів, пов’язаних з вимогами упродовж всього життєвого циклу останніх.

5) Керування конфігурацією:

— ведення історії змін вимог — всі зміни супроводжуються інформацією про те, хто, коли, де, як, з якою причини вніс зміни до вимог. Деякі функції виконуються автоматично, а деякі — з обов’язковою участю користувача, наприклад, обґрунтування змін і визначення, як їх слід виконувати. Як правило, об’єкти можна «дезактивувати», але не можна видалити. Історія проекту доступна для пошуку, сортування, фільтрації та порівняння;

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

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

6) Документи та інші звіти:

— підтримка стандартних форматів специфікації документів — можуть підтримуватись як комерційні, так і інші (військові) стандарти: MilStd490, 498, 961, 2167; IEEE1220; DoD5000; EIA632; DoDAF. Передбачається генерування/експорт звітів у форматах Word, PDF, Excel, Crystal, RTF, ASCII, XML, HTML, CSV, Postscript, SVG, Wiki тощо;

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

— генерування презентацій з таблицями і графами;

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

— попередній перегляд підготовлених звітів перед друком, якщо таке необхідно. Звіти, що генеруються у форматі HTML, є актуальними у будьякий момент;

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

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

У Cradle великі і складні документи формуються з використанням Microsoft Word на основі бази даних проекту і шаблонів Word, побудованих за допомогою тегів і закладок, макетів і форматів. Припускаються як шаблони, визначені користувачем, так і типові, зокрема SEMP (Systems Engineering Management Plan, план керування інжинірингом систем), PBS (Performance Requirements Based Specification, специфікація вимог щодо якості), SRS (специфікація системних вимог), IRS (Interface Requirements Specification, специфікація вимог щодо інтерфейсу), SDD (System Design Description, опис проекту системи). Доступні також шаблони RTM (Requirements Traceability Matrix, матриця трасування вимог) і VCRM (Verification Cross Reference Matrix, матриця перехресних посилань верифікації). Спеціальна модель дає можливість опублікувати розділи бази даних або документа як компоненти Webсайта із гіперпосиланнями. Для легкості використання і перегляду діаграми при цьому записуються як SVGфайли з відповідними гіперпосиланнями.

Система Optimal Trace має функцію «зворотного інжинірингу» сформованих документів з можливістю злиття і прийняттям/відміною кожної із виконаних змін.

7) Групова робота:

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

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

Система керування конфігурацією контролює версії вимог поряд з іншими артефактами проекту і виокремлює серед них базові версії.

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

Серед конкретних програмних засобів, з якими системи керування вимогами обмінюються даними, передусім слід назвати офісні додатки (Microsoft Office), засоби моделювання та розробки додатків (IBM Rational Rose, IBM Rational System Modeler, AllFusion Process Modeler, Microsoft Visual Studio тощо), системи керування проектами (Microsoft Project), засоби управління конфігурацією (IBM Rational ClearCase, PVCS, Visual Source Safe, Subversion, CVS тощо), засоби тестування та забезпечення якості (HP QualityCenter, IBM Rational Test Manager), генератори звітів (Crystal Reports).

Як правило, доступ до баз даних інших засобів інжинірингу та керування проектами забезпечується за допомогою API, SQL, ODBC, інших стандартних мов запитів. API також підтримує додатки VB та VBA. Обмін із засобами моделювання відбувається через UML/SySML, обмін документами — через RTF, MIF, OPS, обмін даними — через CSV, XML, XMI, SVG та ін.

9) Системне середовище:

— підтримка роботи окремого або численних користувачів; — численні платформи та/або операційні системи — MS Windows, Linux, Unix, Solaris, IBM AIX, Mac, HPUX;

— комерційні або унікальні (розроблені спеціально для системи керування вимогами) бази даних — MS SQL Server, MySQL, MS Access, Oracle, HSQL, IBM Derby тощо;

— вимоги до ресурсів — конфігурації технічного і програмного забезпечення — пам’яті, процесора, обсягу жорсткого диска тощо.

10) Користувацький інтерфейс:

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

— синхронне оновлення відкритих форм — якщо засіб надає можливість одночасного відкриття кількох вікон/форм, то зміни, виконані в одному з них, мають відображатися в інших;

— інтерактивне графічне введення та контроль даних;

— підтримка стандарту вікон;

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

— інтерфейс Webбраузера;

— підтримка функцій відміни змін під час редагування.

11) Стандарти, що підтримуються, включно зі стандартами баз даних, вихідних документів, обміну даними, графіки тощо.

Системи можуть підтримувати різні процеси керування вимогами (екстремальне eXtremeRM, RUP, об’єктноорієнтований процес Object Engineering або процес, визначений користувачем). Крім цього, підтримуються стандарти керування користувачами, захисту даних, обміну даними тощо.

12) Підтримка і супровід:

— гарантія;

— політика ліцензування мережного використання;

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

— допомога в режимі онлайн;

— Webсторінка в Інтернеті;

— підтримка за телефоном;

— група підтримки користувачів.

13) Навчання:

— навчальні курси з даної системи керування вимогами;

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

— інсталяція ПЗ із застосуванням базових умінь.

14) Додаткова функціональність.

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

Приклади додаткових завдань, що їх виконують за допомогою систем керування вимогами (їх окремих модулів):