9.2.5.Сценарій аналізу задач користувачів10

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

10Варіанти використання і сценарії використання

10.1 Варіант використання

Варіант використання (use case)¹¹ - це окреме, незалежне дія, яка дійова особа може виконати для отримання певного значущого результату. Один варіант використання може охоплювати кілька схожих завдань з однаковими цілями. Отже, він являє собою набір пов'язаних між собою сценаріїв використання, де сценарій - це окремий приклад варіанту використання. Можна почати розробку вимог з абстрактних варіантів використання, а потім на їх основі створити конкретні сценарії використання або, навпаки, перейти від якогось сценарію до більш широкого варіанту використання.

До важливих елементів опису варіанта використання належать:

– унікальний ідентифікатор;

– ім'я, коротко описує завдання користувачі у форматі «дієслово + об'єкт», наприклад «розмістити замовлення»;

– короткий текстовий опис на природній мові;

– список попередніх умов, які повинні бути задоволені до початку розробки варіанта використання;

– вихідні умови, які описують стан системи після успішного завершення розробки варіанта використання;

– пронумерований список дій, що ілюструє послідовність етапів взаємодії особи і системи від попередніх умов до вихідних умов.

10.2 Сценарій використання

Сценарій використання¹² , варіант використання, прецедент ( Use Case) - у розробці програмного забезпечення та системному проектуванні це опис поведінки системи, як вона відповідає на зовнішні запити. Іншими словами, сценарій використання описує, «хто» і «що» може зробити з розглянутою системою. Методика сценаріїв використання застосовується для виявлення  до поведінки системи, відомих також як .

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

На рисунку 9.1 зображено приклад UML - диаграмме сценарії використання

Рисунок 9.1. UML-діаграма, що ілюструє діалоговий потік

при нормальному та альтернативному розвитку варіанти використання

11Бізнес-правила і вимоги. Документування бізнес-правил

11.1 Бізнес-правила і вимоги

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

Бізнес-правила (business rules) включають корпоративні політики, урядові постанови, промислові стандарти і обчислювальні алгоритми. Не є вимогами до ПО, тому що вони знаходяться зовні меж будь-якої системи ПЗ. Часто накладають обмеження, визначаючи якими функціями повинна володіти система, що підкоряється відповідним правилам. Іноді бізнес-правила стають джерелом атрибутів якості, які реалізуються у функціональності. можете відстежити походження конкретних функціональних вимог аж до відповідних їм бізнес-правил.

Всі бізнес-правила можна розділити на 3 основні категорії: умови, факти і правила. Умови та факти основа для логічної моделі даних і фізичної бази даних. Третя категорія (правила) представляє найбільший інтерес, їх можна розділити на 5 категорій (Рис.10.1.1).¹³

Рисунок 10.1.1 Категорії бізнес-правила

Бізнес-вимоги (business requirements) містять високо рівневі цілі організації або замовників системи. Як правило, їх висловлюють ті, хто фінансують проект, покупці системи, менеджер реальних користувачів, відділ маркетингу.

З точки зору бізнес-цілей в області комерційного ПЗ характеристика являє собою впізнану усіма зацікавленими особами групу вимог, які важливі при ухваленні рішення про покупку в описі продукту. Характеристики продукту, які перераховує клієнт, не еквівалентні тим, що входять в список необхідних для вирішення завдань користувачів.¹⁴