4. Управління вимогами

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

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

1. Великі системи зазвичай мають різноманітний контингент користувачів. Різні користувачі мають різні вимоги і пріоритети, які можуть бути суперечливими або несумісними. Остаточний варіант системних вимог представляє неминучий компроміс між ними, який часто приймається тільки на завершальному етапі розробки системи.

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

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

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

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

4.1. Постійні і змінювані вимоги

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

Рис.4. Еволюція вимог

З точки зору розробки вимоги можна розділити на два класи.

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

2. Змінювані вимоги. Ці вимоги відображують зміни, зроблені під час розробки системи або після введення її в експлуатацію.

Таблиця 1. Класифікація змінюваних вимог

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