Business Analyst English Vocabulary: 70 Essential Terms

Бізнес-аналізатори сидять на перетині бізнес-потреб і технічного забезпечення. Вони постійно пишуть, говорять і презентують англійською мовою — документи з вимогами, семінари для зацікавлених сторін, історії користувачів і моделі процесів. Цей посібник містить 70 термінів, які вам потрібні, щоб впевнено спілкуватися як BA.

---

Типи вимог

Функціональні вимоги

Функціональна вимога описує що система повинна робити — певну поведінку, властивість або функцію.

«Система повинна дозволяти користувачам скидати свій пароль за допомогою електронної пошти»

Нефункціональні вимоги (NFR)

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

«Сторінка реєстрації повинна завантажуватися менше ніж за 2 секунди для 95% користувачів»

Вимоги до бізнесу

** Бізнес- вимога ** описує бізнес- потребу або мету високого рівня — * чому * за проектом.

«Бизнес вимагає портал самообслуговування, щоб зменшити обсяг квитків на підтримку на 30%»

Constraint

** Обмеження ** це обмеження, встановлене на рішення - технічні, регуляторні, часові або бюджетні обмеження.

«Рішення повинно відповідати GDPR і бути розгорнуто на місці»

Assumption

** Припущення ** є твердженням, яке вважається істинним для цілей планування, але ще не перевірене.

Припущення: всі користувачі матимуть доступ до інтернету під час пілотної фази

За межами досяжності

** За межами обсягу ** явно вказує, що проект * не * виконає — запобігає перевантаженню обсягу.

«Мобільні рідні додатки виходять за рамки цього випуску»

---

Вимоги до документації

БД (Документ про бізнес-вимоги)

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

FRS (Функціональні вимоги специфікації)

FRS (також називається SRS — Software Requirements Specification) є докладним документом, що описує кожну функціональну вимогу, включаючи вхідні, вихідні дані і поведінку системи.

Використовувати випадки

** Випадок використання ** описує взаємодію між користувачем (актором) і системою для досягнення певної мети. Він має первинний потік (щасливий шлях) і альтернативні потоки (винятки).

«Службове завдання: замовлення. Актор: Зареєстрований клієнт. Основні напрямки: 1. Замовник вибирає елементи. 2. «Клієнт продовжує чекати…»

Історія користувача

** User story ** це неформальний, короткий опис можливості з точки зору користувача. Стандартний формат: * Як [роля], я хочу [можливості], щоб [цінність для бізнесу].*

«Як менеджер проекту, я хочу експортувати звіти в формат PDF, щоб я міг поділитися ними з зацікавленими сторонами, які не мають доступу до системи»

Критерії прийняття

** Критерії прийняття ** визначають умови, які має задовольняти функціональність, щоб її прийняв власник продукту. Часто написані як Given/When/Then (Gherkin) сценарії.

“У разі, якщо я на сторінці входу, коли я вводжу дійсні дані, то мене перенаправляють на панель управління.”

Правила бізнесу

** Бізнес- правила ** — це правила або умови, які регулюють діяльність бізнесу і які система повинна виконувати.

«Правило бізнесу: клієнт не може зробити замовлення, якщо його баланс на рахунку негативний»

Інформаційний словник

** Словник даних ** — це довідковий документ, у якому визначено кожне поле даних, яке використовується у системі — його назву, тип, формат, дозволені значення і джерело.

Матриця відстежуваності

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

---

Технічні вимоги

MoSCoW

MoSCoW є системою пріоритизації. Кожна вимога поділена на такі категорії:

• ** Потрібно мати ** — критичний; без нього проект зазнає невдачі
• ** Слід було ** — важливо, але не критично
• Могло б бути — гарно, якщо час дозволяє
• Не буде — явно відкладено на майбутню фазу

Після аналізу MoSCoW, команда погодилася, що двофакторна автентифікація є * повинна мати * для MVP

SMART

** SMART ** критерії допомагають написати вимоги високої якості: ** S ** специфічні, ** M ** досягнуті, ** A ** досягнуті, ** R ** відповідні, ** T ** обмежені часом.

INVEST

INVEST використовується для оцінки історій користувачів: Independent, Negotiable, Valuable, Estimable, Ssmall, Testable.

---

Процес моделювання

BPMN (Business Process Model and Notation) — модель бізнес-процесів

** BPMN ** — це стандартизована графічна нотація для моделювання бізнес- процесів за допомогою блок- схем.

Ключові елементи BPMN:

• ** Початок події ** — місце, де починається процес (коло)
• ** Кінець події ** — місце, де процес закінчується (заповнене коло)
• ** Завдання ** — одиниця роботи (заокруглений прямокутник)
• ** Шлюз ** — точка прийняття рішення (ромбовидна)
  • ** Виключний шлюз (XOR) ** — тільки один шлях
  • ** Паралельні шлюз (+) ** — декілька шляхів працюють одночасно
  • ** Включаючи шлюз (O) ** — один або декілька шляхів, заснованих на умовах
• ** Пул ** — представляє організацію або систему
• ** Лінія / Смуга ** — підрозділ пулу, що представляє роль або відділ
• ** Потік послідовності ** — показує порядок дій (зв’ язна стрілка)
• ** Потік повідомлень ** — показує зв’ язок між пулами (пунктирна стрілка)

«Процес схвалення має ексклюзивний шлюз — якщо сума перевищує £ 10,000, вона йде в CFO lane; інакше вона прямує прямо до фінансової смуги»

Процес АС-ИС

** AS-IS процес ** документує * поточний * стан бізнес-процесу - як все працює сьогодні, включаючи болючі точки і неефективність.

Будь-який процес

** TO-BE процес ** документує * майбутній * бажаний стан - як процес буде працювати після того, як рішення буде реалізовано.

Аналітичний аналіз

** Аналіз розривів ** порівнює стани AS-IS і TO-BE, щоб визначити, які зміни необхідні.

«Аналіз прогалин виявив три ручні передачі, які можуть бути автоматизовані в процесі TO-BE»

Діаграма плавального шляху

Діаграма swimlane організовує кроки процесу у горизонтальні або вертикальні смуги за ролями або відділами. Це робить відповідальність зрозумілою на перший погляд.

---

Технічні вимоги

Elicitation

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

Поширені методи виникнення:

• ** Інтерв’ю ** — структурована або напівструктурована розмова один на один
• ** Семінар / сесія JAD ** — сесія спільної роботи групи (спільна розробка застосунків)
• ** Спостереження ** — спостереження за виконанням користувачами своїх завдань (тенетне спостереження за завданнями)
• ** Анкета / Опитування ** — збір даних від великої групи
• ** Аналіз документів ** — перегляд існуючих звітів, форм і процедур
• ** Прототипування ** — використання дротяних моделей або макетів для візуального представлення вимог

Пейнт-Пойнт

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

«Ключовим болем було те, що одобряючі особи повинні були ввійти в три окремі системи, щоб завершити одне схвалення»

Bottleneck

** Вузький кут ** — це крок у процесі, який обмежує пропускну здатність — робота накопичується у черзі на завершення.

Workaround

** workaround ** це неофіційне виправлення або вручну виконаний крок, який користувачі виконують, щоб компенсувати відсутню системну функцію. Важливо документувати обхідні шляхи — вони виявляють незадоволені потреби.

---

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

Реєстр учасників

** Реєстр зацікавлених сторін ** це документ, що містить список всіх зацікавлених сторін, їх ролі, інтереси, рівень впливу і переваги спілкування.

Матриця

Матриця RACI призначає відповідальність за кожне завдання або рішення:

• Респонсибель — виконує роботу
• Aaccountable — в кінцевому підсумку відповідальний
• ** C ** consulted — надає вхідні дані
• Informed — держать в курсе

Експерт (англ. Expert)

** МСП ** це людина з глибокими знаннями про певну діяльність або процес. BAs покладаються на МСП під час вилучення.

Підписання

** Підписання ** означає офіційне схвалення — учасник переглядає і офіційно приймає документ, вимогу або результат.

“Ми потребуємо підпису від юридичної команди, перш ніж ми зможемо завершити вимоги зберігання даних.”

Скоуп Крип

** Поширення обсягу ** — це неконтрольоване зростання обсягу проекту, коли додаються нові вимоги без оцінки впливу на час, вартість і ресурси.

«Додання функції панелі управління в середині спринту є обсягом похилення — це не було в узгодженому запізненні»

---

Словник-довідник з лексикографії

Продуктовий кошик

** Затримка розробки продукту ** — це список з урахуванням пріоритетів всіх історій користувачів, можливостей і виправлень помилок для продукту. Власник продукту, регулярно оновлюється.

Epic

** Епічний ** це велика історія користувача, яку не можна завершити за один спринт. Він розбитий на дрібніші історії.

«The ‘User Account Management’ epic was split into six user stories for the first two sprints.» (англійською)

Історія картографії

** Відображення історій ** — це візуальна техніка для впорядкування історій користувачів за двома вимірами: шлях користувача (горизонтальний) і пріоритет/ подробиці (вертикальний). Це допомагає командам зрозуміти повний обсяг продукту.

Визначення дійсного (до) (англ. Done (DoD))

** Визначення виконано ** — це перевірковий список критеріїв, які слід задовольнити, щоб можна було назвати робочий елемент завершеним. Прикладні критерії: переглянутий код, написані тести, оновлена документація, розгорнуто до стадії розробки.

MVP (Minimum Viable Product) — мінімальний життєздатний продукт

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

Velocity

** Швидкість ** — середня кількість очок історії, які команда закінчує за спринт. Використовується для прогнозування.

---

Аналітичний аналіз даних

Диаграма потоку даних (DFD)

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

Диаграма відносин (англ. Entity-Relationship Diagram, ERD)

** ERD ** показує сутності в системі і взаємозв’ язки між ними. Використовується під час моделювання даних.

Міграція даних

** Міграція даних ** — це процес перенесення даних з однієї системи до іншої, зазвичай, під час заміни або оновлення системи. Потрібне відображення даних, очищення і перевірка.

Правило перевірки даних

** Правило перевірки даних ** обмежує, які дані можна вводити до системи — наприклад, формат дати, дозволені значення, обов’ язкові поля.

---

Використовується для аналізу бізнес-процесів

** В мастерских: **

• “Чи не могли б ви провести мене крок за кроком по поточному процесу?”
• • “Що трапляється, коли X не вдається?” *
• “Хто відповідає за цей крок?”
• “Чи це завжди так, чи це залежить від Y?”

** У перегляді вимог: **

• “Ця вимога неоднозначна — чи можемо ми зробити її вимірюваною?”
• “Це обов’язковий або обов’язковий елемент для першого випуску?”
• “Це суперечить обмеженню в розділі 4 — як ми повинні розв’ язати це?”

При виході:

• “Нам нужна ваша подпись на этом документе до пятницы.”
• “Чи є якісь відкриті питання перед тим, як ми визначимо ці вимоги?”

---

Practice

Готові вправлятися у словниковому запасі? Спробуйте ** Набір вправ з словниковим запасом для бізнес- аналітиків. Name ** — 5 вправ, що охоплюють термінологію вимог, BPMN і фрази вибору.

Досліджуйте повний ** Підручник для студентів-економістів ** для вправ, підготовки до інтерв’ ю і рекомендованого читання.