Документація – важливий аспект роботи будь-якого бізнес-аналітика.
Документація необхідна для відображення вимог і детального обговорення нових функцій та запитів на зміни, якщо такі зʼявляються. Бізнес-аналітики створюють багато різновидів документів. Ось декілька з найважливіших:
- Business Requirement Document (BRD) – документ бізнес-вимог
- User Stories – історії користувачів
- Use Case Specification Document – специфікація сценаріїв використання
- Functional Requirement Document (FRD) – документ функціональних вимог
- Requirements Traceability Matrix (RTM) – матриця відстежуваності вимог
- Market Requirements Document (MRD) – документ вимог ринку
- Product Requirements Document (PRD) – документ продуктових вимог
Окрім наведених прикладів, бізнес-аналітики створюють й інші документи. Це допомагає зрозуміти бізнес-процеси та бізнес-івенти. Бізнес-івент – це тригер, що породжує вимогу. Ці вимоги виконуються шляхом вибору ІТ-рішення. Схематично документи можна зобразити як прості аркуші паперу, що містять певну корисну інформацію. Розглянемо, чим подібні та чим разюче відмінні документи бізнес-вимог (BRD) і функціональних вимог (FRD).
Документ з бізнес-вимогами (Business Requirement Document)
- У BRD висвітлюються “бізнес-вимоги”, тобто високорівневі бізнес-цілі організації, що розробляє продукт чи рішення за допомогою ІТ.
- Іншими словами, він дуже високорівнево описує функціональні специфікації програмного забезпечення
- Це формальний документ, що відображає надані клієнтом вимоги
- Вимоги можуть бути зібрані в усній формі, письмовій, або в обох
- Зазвичай створюється бізнес-аналітиком, який взаємодіє з клієнтом
- Створюється під контролем проджект-менеджера
- Створюється на основі взаємодії з клієнтом та його вимог
Важливе значення BRD полягає в тому, що він є основою для всіх наступних складових проекту, описуючи, які вхідні та вихідні дані пов’язані з кожною функцією процесу. Він описує, як виглядатиме система з точки зору бізнесу. Найпоширеніші цілі BRD:
- Досягнення спільного розуміння зі стейкхолдерами
- Забезпечення вхідних даних для наступного етапу проєкту
- Обґрунтування, як обране рішення задовольнить потреби клієнта/бізнесу
- Цілісний підхід до бізнес-потреб за допомогою стратегії, яка забезпечить цінність для клієнта
Зверніть увагу: Що таке документ бізнес-вимог (Business Requirements Document)
Вимоги стейкхолдерів можуть бути дрібними або масштабними, тому за потреби необхідно декомпозувати їх та обробляти як окремі вимоги.
Формат BRD
Існує багато форматів і шаблонів, однак їх використання залежить від того, яких практик дотримується організація. Для продуктової компанії формат BRD відрізнятиметься від формату в сервісній компанії. Стандартний формат, який використовують більшість організацій, наведений нижче. Важливо зазначити, що для чіткого розуміння документу необхідно включити в нього список використаних абревіатур і скорочень.
Шаблон BRD містить:
- історію змін документу
- затвердження документу
- RACI матрицю
- вступ
- бізнес-цілі
- бізнес-завдання
- бізнес-правила
- контекст
- завдання проєкту
- обсяг проєкту
- опис функціональності, що входить в обсяг проєкту
- інформацію про функціональність поза межами проєкту
- гіпотези
- обмеження
- ризики
- огляд бізнес-процесів (наприклад, у вигляді діаграми варіантів використання та діаграми діяльності)
- успадковані системи
- рекомендації
- бізнес-вимоги
- додатки
- список скорочень і абревіатур
- глосарій термінології
- повʼязані документи
Тепер спробуємо копнути глибше у FRD.
Документ функціональних вимог (Functional Requirement Document)
- FRD описує “функціональні вимоги”, тобто деталі функціональності програмного забезпечення
- Залежно від продукту, обсяг FRD може становити від 10 до 100 сторінок
- Як і BRD, високорівнево описує функціональну і технічну специфікацію програмного забезпечення
- Зазвичай створюється бізнес-аналітиком під наглядом технічного експерта, наприклад, системного архітектора
- У малих та середніх компаніях цим документом займається лише бізнес-аналітик
- Іноді компанії не користуються FRD, якщо BRD достатньо деталізований
- FRD створюється на основі BRD
Ще одна хороша стаття тут: UML – панацея, отрута чи альтернатива BPMN?
Власне, процес досягнення очікувань з BRD і є FRD. При цьому аналітик після обговорень зі стейкхолдерами і проджект-менеджером обмірковує такі питання:
- Як ми імплементуємо очікувані вимоги?
- Які характеристики та функціональність має продукт?
- Які інструменти і/або системи використовуються та які є залежності між ними?
- Якою буде реакція замовника, коли він почне використовувати запропоноване рішення?
- Будь-які гіпотези чи обмеження?
Найпоширеніші завдання FRD:
- Відображення кожного сценарію для кожної взаємодії з системою, включаючи взаємозалежності
- Цілісна картина усіх вимог, кроки їх втілення
- Детальна оцінка ризиків для кожного нового запиту на зміни
- Підкреслення наслідків нездорових рішень щодо проєкту для уникнення неконтрольованого збільшення обсягів робіт
FRD має описувати операції та дії, які повинна виконувати система.
Формат FRD
Як і BRD, FRD має дещо відмінні формати, більше сфокусовані на ризиках та інтерфейсах. Проте немає стандартного формату, який повинен використовувати бізнес-аналітик. Компанії з різних сфер користуються власними шаблонами. Наприклад, багато пунктів можуть повторювати пункти з BRD. Але це не повинно бентежити бізнес-аналітика при підготовці цього документу.
Шаблон FRD містить:
- вступ – має складатися з мети, обсягу, контексту, посилань на джерела, гіпотез і обмежень, огляду документа
- методологію
- функціональні вимоги
- діаграми та схеми – контекстна діаграма, схема вимог користувачів, Data Flow діаграма, логічна модель даних/словник даних, схема функціональних вимог
- інші вимоги – вимоги до інтерфейсу, апаратного/програмного забезпечення
- глосарій
Використання BRD чи FRD залежить від політики організації, усталених практик проєкту та стейкхолдерів. Приміром, у моїй компанії всі проекти переходять від Waterfall до Agile. Якщо стейкхолдерам підходить попередній формат документації, бізнес-аналітик продовжить його використовувати. Та якщо виникне потреба безперервного постачання робочих версій продукту, формат документації буде змінено. Тим не менш, навіть у далекій перспективі документація залишатиметься актуальним артефактом будь-якого проєкту.
Оригінальна стаття – BRD Vs FRD від Arpan Rewatkar з сайту BA Times, переклад – Марія Слободян, ревью – Іван Вільчавський. Зображення від DALL-E.