4.2 Методичні вказівки до заняття

Під час виконання збирання та аналізу вимог слід розрізняти два рівні деталізації: визначення вимог та специфікація вимог.

Визначення вимог призначене для формалізації очікуваного користувачем від системи сервісу. Наприклад, коректним є таке визначення вимоги:

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

Специфікація для цієї вимоги може виглядати наступним чином:

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

Відомо, що вимоги можуть бути згруповані на функціональні та не функціональні. Для опису функціональних вимог можна скористатися з такого шаблону:

• назва функціональної вимоги;

• вхідні данні – змістовний опис даних, які потрібні для успішної реалізації функції;

• джерело вхідних даних;

• результат;

• початкова умова – умова, яка має отримати значення «істина» для того, щоб можна було розпочати працювати з функцією;

• кінцева умова – умова, яка отримує значення «істина» після успішного виконання функції;

• побічні ефекти – які зміни в інформаційній системі відбуваються під час виконання функції;

• причина – чому потрібна реалізація функції.

Часта помилка формування нефункціональних вимог – нестача критеріїв, визначених для перевірки вимог. Кожна нефункціональна вимога повинна бути перевірена, для чого потрібний адекватний вибір критеріїв. Деякі критерії наведено в таблиці 4.1.

Таблиця 4.1

Характеристика	Міра
Продуктивність	Кількість транзакцій за секунду Час відгуку
Розмір	Кількість записів у базі даних Потрібний розмір пам'яті
Зручність для користувача	Час, потрібний для навчання Розмір документації
Надійність	Вірогідність помилки транзакції Час між відмовами Доступність (час, коли програма доступна для користувача) Час перезавантаження програми після помилки Вірогідність втрати даних після помилки
Переносимість	Розмір платформозалежного коду Кількість платформ Вартість перенесення

5 Варіанти використання програмної системи

5.1 Ситуаційна вправа

Він почекав, поки Розен пройде мимо, і окликнув його: «Розен, – той зупинився, – ти не зрозумів, я завжди в тебе за спиною». Його давній недруг повільно обернувся і подивився на нього. Вони стояли навпроти один одного, дивлячись один одному в очі. Маленький чоловічок з букетом квітів підійшов до них і про щось говорив. Не можна, відволікатися не можна. Чоловічок почав відходити, але раптом скрикнув і задзвенів. Він миттєво вистрілив, і тільки потім зрозумів, що це – усього лише сон, а дзвонить будильник.

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

Важко зітхнувши, Сергій прийнявся за промальовування діаграми варіантів використання.

Завдання

1. Побудувати діаграму варіантів використання для CRM-системи.

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

Завдання

2. Записати сценарії варіантів використання CRM-системи.

3. Виконати перевірку якості запису сценаріїв варіантів використання.