Управління вимогами до програмного забезпечення (англ. software requirements management) — процес, що включає ідентифікацію, виявлення, документування, аналіз, відстеження, пріоритизацію вимог, досягнення угоди по вимогам і потім управління змінами та інформування відповідних зацікавлених осіб. Управління вимогами — безупинний процес протягом усього проекту розробки програмного забезпечення.
Мета управління вимог полягає в тому, щоб гарантувати, що організація документує, перевіряє і задовольняє потреби та очікування її клієнтів і внутрішніх або зовнішніх зацікавлених осіб. Управління вимогами починається з виявлення і аналізу цілей і обмежень клієнта. Управління вимогами, далі, включає підтримку вимог, інтеграцію вимог і організацію роботи з вимогами та супутньою інформацією, що поставляється разом з вимогами.
Встановлена таким чином відслідкування вимог використовується для того, щоб повідомляти зацікавлених учасників про їх виконання, з точки зору їх відповідності, завершеності, охоплення і послідовності. Відслідкування також підтримує управління змінами як частина управління вимогами, так як вона сприяє розумінню того, як зміни впливають на вимоги або пов'язані з ними елементи, і полегшує внесення цих змін.
Управління вимогами включає спілкування між проектною командою та зацікавленими особами з метою коригування вимог на протязі всього проекту. Постійне спілкування всіх учасників проекту важливо для того, щоб жоден клас вимог не домінував над іншими. Наприклад, при розробці програмного забезпечення для внутрішнього використання у бізнесу можуть бути настільки сильні потреби, що він може проігнорувати вимоги користувачів, або вважати, що створені сценарії використання покриють також і власні вимоги.
Відслідкування вимоги фактично означає документування всього життєвого циклу вимоги. Часто необхідно дізнатися першоджерело кожної вимоги. Для цього всі зміни вимог повинні бути задокументовані, щоб досягти отслежіваемості. Відслідковувати повинно бути навіть використання реалізованих вимог.
Вимоги виходять із різних джерел, таких як ділова людина, яка замовляє продукт, менеджер збуту і фактичний користувач. У всіх цих людей є різні вимоги до продукту. Використовуючи відслідкування вимог, реалізована в системі функція може бути простежено назад до людині або групі, яка замовляла її під час збору вимог. Ця особливість може, наприклад, використовуватися в процесі розробки для пріоритезації вимог, визначаючи, наскільки цінним є дана вимога для певного користувача. Відслідкування може також використовуватися після розгортання. Наприклад, коли вивчення використання системи показує, що якась функція не використовується, можна визначити, навіщо вона потрібна була спочатку.
На кожному етапі процесу розробки існують ключові методи і завдання, пов'язані з управлінням вимогами. Для ілюстрації розглянемо приміром стандартний процес розробки з п'ятьма фазами: дослідженням, аналізом здійснимості, дизайном, розробкою і тестуванням і випуском.
Під час фази дослідження збираються перші три класи від вимог користувачів, бізнесу і команди розробників. У кожній області задають однакові питання: які цілі, які обмеження, які використовуються процеси, інструменти і так далі. Тільки коли ці вимоги добре зрозумілі, можна приступати до розробки функціональних вимог.
Тут потрібно застереження: незалежно від того, як сильно група намагається вимоги не можуть бути повністю визначені на початку проекту. Деякі вимоги змінюються, або тому що вони просто не були знайдені спочатку, або тому що внутрішні чи зовнішні сили впливають на проект в середині циклу. Таким чином, учасники групи повинні спочатку погодитися, що головна умова успіху — гнучкість в мисленні та діях.
Результатом стадії дослідження є документ — специфікація вимог, схвалений усіма членами проекту. Пізніше, в процесі розробки, цей документ буде важливий для запобігання розповзання меж проекту або непотрібних змін. Оскільки система розвивається, кожна нова функція відкриває світ нових можливостей, таким чином специфікація вимог прив'язує команду до оригінального бачення системи і дозволяє контрольоване обговорення змін.
У той час як багато організацій все ще використовують звичайні документи для керування вимогами, інші управляють своїми базовими вимогами, використовуючи програмні інструменти. Ці інструменти керують вимогами використовуючи базу даних, і зазвичай мають функції автоматизації отслежіваемості (наприклад, дозволяючи створювати зв'язки між батьківськими і дочірніми вимогами, або між тестами і вимогами), управління версіями, і управління змінами. Зазвичай такі інструментальні засоби містять функцію експорту, яка дозволяє створювати звичайний документ, експортуючи дані вимог.
На стадії аналізу здійсненності визначається вартість вимог.
Для користувацьких вимог поточна вартість роботи порівнюється з майбутньою вартістю встановленої системи. Задаються питання такі як: «Скільки нам зараз стоять помилки введення даних?» Або, «Яка вартість втрати даних через помилки оператора пов'язаної з використовуваним інтерфейсом?». Фактично, потреба в новому інструменті часто розпізнається, коли подібні питання потрапляють під увагу людей, які займаються в організації фінансами.
Ділова вартість включає відповіді на такі питання як: «У будь відділу є бюджет для цього?» «Який рівень повернення коштів від нового продукту на ринку?» «Який рівень скорочення внутрішніх витрат на навчання та підтримку, якщо ми зробимо нову, більш просту у використанні систему?»
Технічна вартість пов'язана з вартістю розробки програмного забезпечення та апаратної вартістю. «Є у нас потрібні люди, щоб створити інструмент?» «Чи потребуємо ми новому обладнанні для підтримки нової системи?»
Подібні питання дуже важливі. Група має з'ясувати, чи буде новий автоматизований інструмент мати достатню ефективність щоб перенести частину тягаря користувачів на систему і економити час.
Ці питання також вказують на основну суть управління вимогами. Людина і інструмент формують систему, і це розуміння особливо важливо, якщо інструмент — комп'ютер або новий додаток на комп'ютері. Людський розум вкрай ефективний у паралельній обробці та інтерпретації тенденцій з недостатніми даними. Комп'ютерний процесор ефективний у послідовній обробці і точному математичному розрахунку. Основна мета управління вимогами для програмного проекту полягала б у тому, щоб гарантувати, що автоматизируемая робота призначена «правильному» процесора. Наприклад, «не змушуйте людини пам'ятати, де вона знаходиться в системі. Примусьте інтерфейс завжди повідомляти про місцезнаходження людини в системі». Або «не змушуйте людини вводити ті ж самі дані у два екрани. Примусьте систему зберігати дані і заповнювати їх де необхідно автоматично».
Результатом стадії аналізу здійсненності є бюджет і графік проекту.
Якщо вартість точно визначена, та переваги, які будуть отримані, є досить великими, тоді проект може перейти до стадії проектування.
На стадії проектування основна діяльність управління вимог полягає в тому, щоб перевіряти, чи відповідають результати дизайну документом вимог, щоб упевнитися, що робота залишається в межах проекту.
І знову, гнучкість є ключем до успіху. Ось класичний приклад змін проекту, які фактично відмінно працювали. Проектувальники Форда на початку 1980-х очікували, що ціни на бензин піднімуться до 3,18 дол. за галон до кінця десятиліття. На середині дизайну автомобіля Ford Taurus ціни встановилися приблизно на 1,50 дол. за галон. Колектив дизайнерів вирішив, що вони могли б створити більший, більш зручний і більш потужний автомобіль, якщо б ціни на бензин залишилися низькими. Таким чином, вони перепроектувати автомобіль. Коли новий автомобіль вийшов, він встановив загальнонаціональні рекорди продажів.
У більшості випадків, однак, відступ від оригінальних вимог до такої міри не працює. Таким чином, документ вимог стає ключовим інструментом, який допомагає команді приймати рішення про зміни дизайну.
На стадії розробки та тестування основне завдання управління вимогами — гарантувати, що робота і ціна залишаються в межах графіка і бюджету, і що створюваний інструмент дійсно відповідає вимогам. Основним інструментом, використовуваним на цій стадії, є створення прототипу і ітераційне тестування. Для програмного додатка користувальницький інтерфейс може бути створений на папері і перевірений з потенційними користувачами в той час, як створюється основа програми. Результати цих тестів записуються в керівництві по дизайну користувальницького інтерфейсу і передаються колективу дизайнерів. Це економить їх час і робить їх завдання набагато простіше.
Управління вимогами не закінчується випуском продукту. З цього моменту отримані дані про прийнятність додатки збираються і використовуються під час фази дослідження для наступного покоління системи або випуску. Таким чином, процес починається знову.
Існує безліч програмних продуктів для автоматизації управління вимогами, що розрізняються ціною та функціональними можливостями.
Є як комерційні пакети: IBM Rational RequisitePro, Borland CaliberRM, Sybase PowerDesigner, так і безкоштовні (наприклад, OSRMT — Open Source Вимога Management Tool).
