8.3. Питання для самоконтролю:

1. Від чого залежить вибір різних мов та методик моделювання при аналізі вимог?

2. Побудуйте діаграму варіантів використання UML (Use Case Diagram) для питання№4 з теми №7

3. У яких випадках доцільно використовувати діаграми класів, станів, дій UML при аналізі вимог?

Тема №9. Розширений аналіз вимог. Ілюстровані сценарії і прототипи

9.1. Методичні вказівки до вивчення теми

Цілі прототипування

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

Розглянемо основні цілі, що вимагають застосування прототипів [1-2]:

• прояснити неясні вимоги до системи;

• вибрати одне з декількох концептуальних рішень;

• проаналізувати здійсненність.

1. Неясні вимоги. Часто Замовникові буває важко сформулювати вимоги до того, що він чекає від системи. У цьому випадку прототип інтерфейсу користувача (User Interface, UI), оперативно створений за результатами інтерв'ю, дає йому можливість побачити схематичну реалізацію того, як виконавець побачив відповідну частину системи. Цікаво, що у даному випадку корисний будь-який результат прототипування: якщо виконавець зрозумів вимоги добре, користь очевидна; якщо не дуже – користь полягає у тому, що замовник може вказати, у чому полягає нерозуміння, тим самим вирішивши основне завдання, – зробити неясне ясним.

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

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

А. Сценарій послідовної обробки вимог.

А1. Система відображає реєстр вимог, наявних у вхідній черзі.

А2. Користувач вибирає чергову вимогу.

А3. Система відображає перелік матеріалів вимоги і довідник постачальників.

А4. Користувач зіставляє кожній з позицій вимоги постачальника з довідника постачальників.

А5. Система надає вимозі статус «оброблено», відсилає електронною поштою повідомлення автору вимоги.

А6. Продовжувати з кроку А1, доки черга не спорожніє.

Б. Сценарій групування за матеріалами.

Б1. Система відображає позиції усіх вимог і довідник постачальників.

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

Б3. Користувач вибирає групу позицій і зіставляє їй постачальника.

Б4. Система перевіряє, чи не з'явилися повністю оброблені вимоги. При позитивному результаті перевірки привласнює цим вимогам статус «оброблено» і відсилає електронною поштою повідомлення автору вимоги.

Б5. Продовжувати з кроку Б1, доки черга не спорожніє.

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

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

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