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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

3. Техніка блок-схеми

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

IDEF або Integrated Definition for Function Modeling — це загальна назва для класів мов корпоративного моделювання. Він використовується для моделювання дій, необхідних для підтримки системного аналізу, проектування або інтеграції. Для IDEF існує близько 16 методів, найкориснішими версіями IDEF є IDEF3 і IDEF0.

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

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

Об'єкти мережі Петрі мають специфічний напис типу for

• місця: має такі написи, як .Name, .Color Set, .Initial marking тощо.
• Transition : має напис на зразок .Name (для ідентифікації) та .Guard (логічний вираз складається з деяких змінних)
• дуги: має напис, як .Arc. Коли вираз дуги оцінюється, він дає кілька наборів кольорів маркерів.

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

Техніка робочого процесу — це візуальна діаграма, яка представляє один або кілька бізнес-процесів для уточнення розуміння процесу або надання рекомендацій щодо його вдосконалення. Так само, як і інші діаграми, такі як блок-схеми, діяльність UML і карта процесу, метод робочого процесу є найстарішим і популярним. Він навіть використовується BA для нотаток під час виявлення вимог. Процес складається з чотирьох етапів

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

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

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

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

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

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

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

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

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