Поняття прецеденту системи. Класифікація прецедентів, документування опису прецедентів різних класифікаційних груп.

Прецедент (use case) – документ, що описує послідовність подій, що пов’язані з виконавцем, який для здійснення необхідного процесу використовує систему. Прецедент є описом або варіантом використання системи.

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

♦ отримання грошей з банкомату;

♦ замовлення продукції;

♦ перевірка орфографії в документі;

♦ обробка телефонного дзвінка.

Типовою помилкою є подання прецедентом окремих кроків, операцій або транзакцій.

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

Види діяльності, складові частини або навіть окремі кроки певного прецеденту можна розділити на окремі більш дрібні прецеденти, що називаються абстрактними (abstract use case), але така практика не є нормою і зараз розглядатися не буде.

Прецедент верхнього рівня – стисло описує процес в термінах предметної області.

Прецеденти описуються таблицею:

Прецедент	Назва прецеденту
Виконавець	Перелік виконавців (учасників)
Тип	(Див. далі)
Опис	Стислий опис процесу

Розгорнутий прецедент (expended use case) – надаю більш детальний опис, ніж прецедент верхнього рівня. Часто розгорнутий прецедент має форму діалогу між виконавцем та системою. Опис розгорнутого прецеденту складається з декількох частин.

1. Узагальнена інформація.

Прецедент	Назва прецеденту
Виконавець	Перелік виконавців (учасників)
Мета	Мета прецеденту
Опис	Стислий опис прецеденту високого рівня (копія)
Тип	1. Головний, другорядний або додатковий 2. Ідеальний або реальний
Посилання	Прецеденти або функції системи, що пов’язані з цим. Під час визначення функцій системи (етап формування вимог) всі вони мають бути розподілені по прецедентам. Це можна перевірити, переглянувши розділ посилань (cross reference) прецеденту.

2. Типовий хід подій.

Типовий хід подій
Дії виконавця	Відгук системи
Пронумеровані дії виконавця	Пронумерований опис відгуків системи

3. Альтернативний хід подій.

Альтернативи
Номер рядка в типовому ході події, для якого можливі альтернативні варіанти виконання	Відгук системи

Опис розгорнутого прецеденту слід починати за схемою:

1. Цей прецедент починається, коли < Виконавець > < ініціює подію >.

2. Цей прецедент починається, коли клієнт підходить до банкомату і вставляє картку.

Ідеальний прецедент (essential use case) – це розгорнутий прецедент, що виражає тільки сутність процесу без деталізації його реалізації. Проектні рішення, особливо ті, що пов’язані з реалізацією інтерфейсу користувача, при цьому не розглядаються.

Реальний прецедент (real use case) – конкретно описує процес в термінах проектних рішень, на основі конкретних технологій введення/виведення інформації і т. п. Коли йдеться про інтерфейс користувача реальний прецедент визначає вміст діалогових вікон (або описує способи взаємодії з конкретним пристроєм) та обговорення низькорівневої взаємодії користувача з елементами інтерфейсу.

Тип прецеденту

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

Основні прецеденти (primary use case) – являють найбільш загальні процеси.

Другорядні прецеденти (secondary use case) – являють менш значущі або додаткові процеси.

Додаткові прецеденти (optional use case) – описують процеси, які можуть не реалізовуватися системою.