Управління вимогами
 |
Управління вимогами це процес запису, аналізу, трасування, пріоритезації і узгодження вимог та контролю змін і доведення до їх зацікавлених сторін. Це безперервний процес протягом всього життя проєкту. Вимога – якість, якій мають відповідати результати проєкту (продукту або послуги).
Мета управління вимогами полягає в тому, щоб переконатися, що організація відповідає потребам і очікуванням своїх клієнтів, внутрішніх або зовнішніх зацікавлених сторін.[1] Управління вимогами починається з аналізу і виявлення цілей і обмежень організації. Управління вимогами додатково включає в себе підтримку планування вимог, інтеграції вимог і організації роботи з ними (атрибути для вимог).
Управління вимогами передбачає спілкування між членами проєктної групи й зацікавленими сторонами, і адаптацію до змін у вимогах протягом всього проєкту.[2] Щоб запобігти перетину поля одного класу вимог з іншим, постійні зв'язки між членами команди розробників є критичними. Наприклад, при розробці програмного забезпечення для внутрішнього використання у бізнесу можуть бути настільки сильні потреби, що він може проігнорувати вимоги користувачів, або вважати, що створені сценарії використання покриють також і користувальницькі вимоги.
Відслідковування вимоги фактично означає документування всього життєвого циклу вимоги. Часто необхідно дізнатися першоджерело кожної вимоги. Для цього всі зміни вимог повинні бути задокументовані, щоб досягти стану повного відстеження. Відстежувати треба буде навіть використання реалізованих вимог.
Вимоги мають різні джерела, такі як ділова людина, що замовляє продукт, менеджер зі збуту і фактичний користувач. У всіх цих людей є різні вимоги до продукту. Використовуючи відслідковування вимог, реалізована в системі функція може бути простежена назад до людини або групи, яка замовляла її під час збору вимог. Ця особливість може, наприклад, використовуватися в процесі розробки для пріоритезації вимог, визначаючи, наскільки цінною є дана вимога для певного користувача. Відслідковування може також використовуватися після розгортання продукту. Наприклад, коли вивчення використання системи показує, що якась функція не використовується, можна визначити навіщо вона була потрібна спочатку.
На кожному етапі процесу розробки існують ключові методи й задачі пов'язані з управлінням вимогами. Для ілюстрації, розглянемо, наприклад стандартний процес розробки з п'ятьма фазами: дослідженням, аналізом здійсненності, дизайном, розробкою та тестуванням і випуском.
Під час фази дослідження збираються перші три класи вимог від користувачів, бізнесу і команди розробників. У кожній області ставлять однакові питання: які цілі, які обмеження, які використовуються процеси та інструменти й так далі. Тільки коли ці вимоги добре зрозумілі, можна братися до розробки функціональних вимог.
Тут необхідне застереження: незалежно від того, як сильно група намагається це зробити, вимоги не можуть бути повністю визначені на початку проєкту. Деякі вимоги змінюються, або, тому що вони просто не були знайдені спочатку, або, тому що внутрішні чи зовнішні сили торкаються проєкту в середині циклу. Таким чином, учасники групи повинні спочатку погодитися, що головна умова успіху — гнучкість у мисленні та діях.
Результатом стадії дослідження є документ — специфікація вимог, схвалений усіма членами проєкту. Пізніше, в процесі розробки, цей документ буде важливий для запобігання розповзання меж проєкту або непотрібних змін. Оскільки система розвивається, кожна нова функція відкриває світ нових можливостей, таким чином специфікація вимог прив'язує команду до оригінального бачення системи й дозволяє контрольоване обговорення змін.
У той час як багато організацій все ще використовують звичайні документи для керування вимогами, інші управляють своїми базовими вимогами, використовуючи програмні інструменти. Ці інструменти керують вимогами використовуючи базу даних, і зазвичай мають функції автоматизації відстеження (наприклад, дозволяючи створювати зв'язки між батьківськими й дочірніми вимогами, або між тестами й вимогами), управління версіями, і управління змінами. Зазвичай такі інструментальні засоби містять функцію експорту, яка дозволяє створювати звичайний документ, експортуючи дані вимог.
На стадії аналізу здійсненності визначається вартість вимог.
Для користувальницьких вимог поточна вартість роботи порівнюється з майбутньою вартістю встановленої системи. Ставляться питання такі як: «Скільки нам зараз варті помилки введення даних?» Або, «Яка вартість втрати даних через помилки оператора пов'язаної з використовуваним інтерфейсом?». Фактично, потреба в новому інструменті часто розпізнається, коли подібні питання потрапляють до уваги людей, що займаються в організації фінансами.
Ділова вартість включає відповіді на такі питання як: «У якого відділу є бюджет на це?» «Який рівень повернення коштів від нового продукту на ринку?» «Який рівень скорочення внутрішніх витрат на навчання і підтримку, якщо ми зробимо нову, більш просту в використанні систему?»
Технічна вартість пов'язана з вартістю розробки програмного забезпечення та апаратною вартістю. «Чи є у нас потрібні люди, щоб створити інструмент?» «Чи потребуємо ми нове устаткування для підтримки нової системи?»
Подібні питання дуже важливі. Група повинна з'ясувати, чи буде новий автоматизований інструмент мати достатню ефективність аби перенести частину тягаря користувачів на систему і зекономити час людей.
Ці питання також вказують на основну суть управління вимогами. Людина й інструмент формують систему, і це розуміння особливо важливе, якщо інструмент — комп'ютер або новий додаток на комп'ютері. Людський розум вкрай ефективний у паралельній обробці та інтерпретації тенденцій з недостатніми даними. Комп'ютерний процесор ефективний у послідовній обробці й точному математичному обчисленні. Основна мета управління вимогами для програмного проєкту полягала б у тому, щоб гарантувати, що автоматизована робота призначена «правильному» процесору. Наприклад, «не змушуйте людину пам'ятати, де вона знаходиться в системі. Примусьте інтерфейс завжди повідомляти про місцезнаходження людини в системі ». Або «не змушуйте людини вводити ті ж самі дані у два екрани. Примусьте систему зберігати дані й заповнювати їх де необхідно автоматично».
Результатом стадії аналізу здійсненності є бюджет і графік проєкту.
Припускаючи, що вартість точно визначена і переваги, які будуть отримані, є досить великими, проєкт може перейти до стадії проєктування.
На стадії дизайну основна діяльність управління вимогами полягає в тому, щоб перевіряти чи відповідають результати дизайну документа вимог, щоб упевнитися, що робота залишається в межах проєкту.
І знову, гнучкість є ключем до успіху. Ось класичний приклад змін проєкту, які відмінно працювали. проєктувальники Форда на початку 1980-х очікували, що ціни на бензин піднімуться до 3,18 дол за галон до кінця десятиліття. На середині процесу дизайну автомобіля Ford Taurus, ціни встановилися приблизно на рівні 1,50 дол за галон. Колектив дизайнерів вирішив, що вони могли б створити більший, більш зручний, і більш потужний автомобіль, якби ціни на бензин залишилися низькими. Таким чином, вони перепроєктували автомобіль. Коли новий автомобіль вийшов, він встановив загальнонаціональні рекорди продажів.
У більшості випадків, однак, відступ від оригінальних вимог до такої міри не працює. Таким чином документ вимог стає ключовим інструментом, який допомагає команді приймати рішення про зміни дизайну.
На стадії розробки й тестування, основна діяльність управління вимогами — це гарантувати, що робота і ціна залишаються в межах графіка і бюджету, і що створюваний інструмент дійсно відповідає вимогам. Основним інструментом, використовуваним на цій стадії, є створення прототипу й ітераційне тестування. Для програмного додатка користувацький інтерфейс може бути створений на папері й перевірений з потенційними користувачами, в той час, як створюється основа програми. Результати цих тестів записуються в керівництві по дизайну користувацького інтерфейсу і передаються колективу дизайнерів. Це економить їх час і робить їх завдання набагато простіше.
Управління вимогами не закінчується випуском продукту. З цього моменту отримані дані про прийнятність додатка збираються і використовуються під час фази дослідження для наступного покоління системи або випуску. Таким чином, процес починається знову.
Існує безліч програмних продуктів для автоматизації управління вимогами, що розрізняються ціною та функціональними можливостями.
Є такі комерційні пакети: IBM Rational RequisitePro, Borland CaliberRM, Sybase PowerDesigner, так і безкоштовні (наприклад, OSRMT — Open Source Requirements Management Tool).
- ↑ Stellman, Andrew; Greene, Jennifer (2005). Applied Software Project Management. O'Reilly Media. ISBN 978-0-596-00948-9. Архів оригіналу за 9 лютого 2015. Процитовано 8 грудня 2012.
- ↑ A Guide to the Project Management Body of Knowledge (вид. 4th). Project Management Institute. 2008. ISBN 978-1-933890-51-7.
- Davis, Alan M. Just Enough Requirements Management: Where Software Development Meets Marketing. — Dorset House, 2005. — 240 p. — ISBN 978-0932633644.