ктування;
- реалізація;
- інтеграція;
- супровід.
Наше завдання розглянути детально перший етап - встановлення вимог. Завданням етапу визначення вимог є визначення, аналіз та обговорення вимог із замовниками. На цьому етапі застосовуються різні методи збору інформації від замовників, і займається цим аналітик бізнес-процесів (системний аналітик). До методів можна віднести дослідження концепції за допомогою структурованих і неструктурованих інтерв'ю користувачів, анкети, вивчення документів і форм, відеозапису і т.д.
Розглянемо вимоги пред'являються користувачами даної системи. У майбутніх користувачів виникають наступні вимоги до розроблюваної системі:
- система повинна зменшити кількість витраченого часу на пошук і обробку інформацію;
- можливість користувачеві при наявності мінімальних знань комп'ютера використовувати програмний продукт;
- система повинна забезпечити достовірність інформації, весь час поповнюючи базу даних, тому що інформація про клієнтів часто оновлюється;
- система повинна проводити аналіз даних з урахуванням різних обмежень, обраних користувачем і відображати результати в табличному вигляді.
Наступним етапом розробки програмного продукту є побудова діаграми прецедентів.
Поведінка системи - так як воно виглядає для зовнішнього користувача - зображується у вигляді прецедентів. Моделі прецедентів можна розробляти на різних рівнях абстракції. На етапі аналізу прецеденти вбирають у себе системні вимоги, концентруючись на тому, що робить або має робити система.
Прецедент виконує бізнес-функцію, яку може спостерігати зовнішній суб'єкт і яка може бути згодом окремо протестована в процесі розробки. Суб'єкт (актор) - це хтось або щось, що взаємодіє з прецедентом, чекаючи в результаті отримати якийсь корисний результат.
Діаграма прецедентів - це документована модель передбачуваного поведінки системи.
Кожен прецедент повинен бути описаний за допомогою документально зафіксованого потоку подій. Відповідний текстовий документ визначає, що повинна робити система, коли актор ініціює прецедент. Структура документа, що описує прецедент, різна, але типове опис має містити такі розділи:
- короткий опис;
- предусловия;
- деталізований опис потоку подій: основний потік і альтернативні потоки;
- постумови.
Діаграма прецедентів показана на малюнку 2.1.
Рисунок 2.1 - Діаграма прецедентів
Для подальшого більш докладного розгляду та документування виділяється прецедент «Формування листа».
Наведемо описову специфікацію даного прецеденту:
а) прецедент дає можливість оператору провести заповнення листа-повідомлення і відобразити результати в текстовий документ;
б) предусловием для даного прецеденту є обов'язкова наявність бази даних;
в) основний потік: інженер відділу білінгу викликає сторінку графічного відображення даних про клієнтів і їх реквізитів (сума боргу, оплата, ЛЗ, поточни...
