Методи аналізу вимог з прикладом

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

Аналіз вимог має a

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

Методи аналізу вимог

Методи аналізу вимог відображають робочий процес у бізнесі, щоб ви могли його аналізувати, розуміти та вдосконалювати.

Наступні методи використовуються по всій розробка програмного забезпечення процесу.

1. Нотація моделювання бізнес-процесів (BPMN)

BPMN (Модель та нотація бізнес-процесу) – це графічне представлення бізнес-процесу за допомогою простих об’єктів, що допомагає організації спілкуватися стандартним чином. Основні об’єкти, що використовуються в BPMN:

• Об'єкти потоку
• З’єднання об’єктів
• Доріжки для плавання
• Артефакти.

Добре розроблена модель BPMN надає детальну інформацію про дії, що виконуються під час процесу, такі як:

• Хто здійснює ці дії?
• Які елементи даних потрібні для цих дій?

Найбільшою перевагою BPMN є те, що діаграмами легко ділитися, і більшість інструментів моделювання підтримують цю нотацію.

2. UML (Уніфікована мова моделювання)

UML- є стандартом моделювання для специфікації, розробкиping, візуалізація та документування програмних систем. UML надає такі об'єкти, як:

• стан
• Об'єкт
• діяльність
• Діаграма класів

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

3. Методика блок-схеми

Блок-схема — це візуальне представлення послідовного потоку та логіки керування набором пов'язаних дій. Поширені формати блок-схем включають лінійний, низхідний та міжфункціональний (плавальні доріжки). Блок-схему можна використовувати для представлення потоків даних, взаємодії систем та етапів процесу. Блок-схеми легко читати та писати навіть для нетехнічних працівників, і вони можуть показувати паралельні процеси та критичні атрибути.

4. Діаграма потоку даних

Діаграми потоків даних показують, як дані обробляються системою з точки зору вхідних та вихідних даних. Компоненти діаграми потоку даних:

• Процес
• Потік
• Магазин
• Термінатор

Логічний DFD показує діяльність; фізичний DFD показує інфраструктуру. DFD може бути розроблений на ранній стадії аналізу SDLC (Життєвий цикл розробки системи) для визначення обсягу проекту. Його можна деталізувати на підпроцеси, відомі як «рівневе DFD».

5. Діаграми рольової діяльності (RAD)

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

• Діяльності
• Зовнішні події
• Штати

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

Зовнішні події позначають точки, де відбуваються зміни стану.

Стани відображають, як роль просувається в процесі. Досягнення стану вказує на досягнення певної мети.

RAD легко читається, він представляє детальний огляд процесу та показує паралельні дії.

6. Діаграми Ганта

Діаграма Ганта — це графічне представлення графіка, яке допомагає координувати, планувати та track конкретних завдань у проекті. Вона показує загальний часовий проміжок проекту, розбитий на прирости. Вертикальна вісь показує завдання; горизонтальна вісь показує орієнтовну тривалість діяльності або призначеного відповідального. Одна діаграма може відображати багато видів діяльності.

7. IDEF (інтегроване визначення для моделювання функцій)

IDEF (Інтегроване визначення для моделювання функцій) охоплює сімейство мов моделювання підприємств. Він моделює діяльність, що підтримує системний аналіз, проектування або інтеграцію. Існує близько 16 методів IDEF; IDEF0 та IDEF3 є найкориснішими.

8. Кольорові мережі Петрі (CPN)

Кольорові мережі Петрі (CPN) – це графічно орієнтована мова для специфікація, перевірка, проектування та моделювання системCPN поєднує графіку та текст. Його основні компоненти: Місця, переходи та дуги.

Об'єкти мережі Петрі мають певні написи, наприклад:

• місцяМістить написи, такі як .Назва, .Набір кольорів та .Початкове маркування.
• Transition Має написи, такі як .Name (для ідентифікації) та .Guard (булевий вираз над деякими змінними).
• дугиМає напис .Arc. Коли обчислюється дуговий вираз, він повертає багатонабір кольорів токенів.

9. Техніка робочого процесу

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

• Збір інформації
• Моделювання робочого процесу
• Моделювання бізнес-процесів
• Впровадження, перевірка та виконання

10. Об'єктно-орієнтовані методи

Метод об'єктно-орієнтованого моделювання використовує об'єктно-орієнтовану парадигму та мову моделювання для проектування системи. Він наголошує на пошуку та описі об'єктів у предметній області. Метою об'єктно-орієнтованого методу є:

• Щоб допомогти охарактеризувати систему
• Щоб ідентифікувати різні відповідні об'єкти
• Щоб зрозуміти, як об'єкти пов'язані один з одним
• Щоб визначити або змоделювати проблему для створення ефективного дизайну
• Проаналізувати вимоги та їх наслідки

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

Об'єкт має стан, а зміни стану представлені поведінкою. Коли об'єкт отримує повідомлення, стан змінюється через поведінку.

11. Аналіз прогалин

Аналіз розривів – це метод, який використовується для визначення різниці між запропонованим станом та поточним станом бізнесу та його функцій. Він відповідає на такі питання, як: Який поточний стан проекту? Де ми хочемо бути? Як нам усунути розрив? Етапи аналізу розривів включають:

• Revсистема iew
• Вимоги до розробки
• порівняння
• Наслідки
• Рекомендації

Поширені запитання