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

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

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

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

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

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

2.1.4. Послідовність роботи з вимогами. Аналіз проблеми

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

Програмісти повинні зрозуміти потреби користувачів та інших зацікавлених осіб.

Наступним кроком здійснюється перехід в область розв’язання – безпосередньо до програмування. Однак для початку буде корисно сформулювати знання про предметну область. На даному етапі створюється список функцій, які повинна реалізовувати система.

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

Іноді самим простим розв’язком є зміна бізнес-процесу, а не створення нової системи. Як завжди, починати потрібно з визначення цілі. Ціль аналізу в тому, щоб добитися кращого розуміння проблеми до початку розробки. Для цього необхідно здійснити наступні п’ять етапів.

1. Досягнути згоди про визначення проблеми.

2. Визначити основні причини – питання, які стоять за проблемою.

3. Виявити зацікавлених осіб та користувачів.

4. Визначити межу системи розв’язання.

5. Визначити обмеження, які необхідно накласти на розв’язання.

Етап 1. Досягання згоди про визначення проблеми.

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

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

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

Таблиця 2.1. Структурування проблеми

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

Етап 2. Виявлення основних причин – запитання, які постають за проблемою.

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

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

1. застарілі готові вироби;

2. неправильні замовлення на покупку;

3. пошкодження при доставці;

4. виробничі дефекти;

5. повернення клієнтами та ін.

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

Етап 3. Виявлення зацікавлених осіб і користувачів.

У цьому процесі можуть допомогти відповіді на наступні запитання:

• Хто є користувачем системи?

• Хто є замовник (економічний замовник) системи?

• На кого ще будуть мати вплив результати роботи системи?

• Хто буде оцінювати і приймати систему, коли вона буде представлена і розгорнута?

• Чи існують ще інші зовнішні або внутрішні користувачі системи?

• Хто буде займатися супроводженням нової системи?

• Чи не забули ми ще когось?

Етап 4. Визначення меж системи.

Світ ділиться на дві частини:

• система яка створюється;

• те, що взаємодіє з системою – фактор.

Дуже важливо правильно визначити фактори. Для цього слід відповісти на запитання:

• Хто буде керувати системою?

• Хто буде виконувати супроводження системи?

• Звідки система отримує інформацію?

• Які зовнішні системи будуть взаємодіяти з системою?

Етап 5. Виявлення обмежень, які накладаються на розв’язок.

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

Таблиця 2.2. Можливі джерела обмежень системи

Джерело	Зразки запитань
Економічне	Які фінансові чи бюджетні обмеження слід врахувати? Чи існують міркування які зачіпають собівартість і ціноутворення? Чи існують питання ліцензування?
Політичне	Чи існують зовнішні чи внутрішні політичні питання, які впливають на потенційне рішення? Чи існують проблеми у відносинах між підрозділами?
Технічне	Чи існують обмеження у виборі технологій? Чи повинні ми працювати в рамках існуючих платформ чи технологій? Чи заборонено використання будь яких нових технологій? Чи повинні ми використовувати будь-які пакети програмного забезпечення які закуповуються?
Системне	Розв’язок буде створюватись для існуючих систем? Чи повинні розробники забезпечувати сумісність з існуючими розв’язками? Які операційні системи і середовища повинні підтримуватись?
Експлуатаційне	Чи існують обмеження інформаційного середовища чи правові обмеження? Юридичні обмеження? Вимоги безпеки? Якими іншими стандартами обмежені розробники?
Графіки і ресурси	Чи обмежена команда програмістів наявними ресурсами? Чи можуть розробники запрошувати співробітників зі сторони? Чи можна збільшити штат? Тимчасово?