Що таке BRD (Business Requirements Document)

Що таке документ бізнес-вимог?

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

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

Зазвичай, BRD (Business Requirements Document) розробляє бізнес-аналітик, а основними споживачами викладеної в ньому інформації є Замовник, Менеджер проекту та Системний аналітик. Цей документ створюється на початку будь-якого проекту або навіть на стадії передпроектного дослідження (discovery) і містить як мінімум наступні пункти:

Короткий опис проекту;

Цілі проекту;

Бізнес-контекст поточної ситуації (as is);

Внутрішнє бачення бажаної ситуації (as to be), включаючи бачення рішення;

Межі та зміст проекту (scope);

Бізнес-вимоги;

Ключові стейкхолдери;

Основні вимоги стейкхолдерів;

Обмеження проекту.

При розробці документа знадобляться такі техніки бізнес-аналізу:

BACCM (Business Analysis Core Concept Model) – модель базових понять бізнес-аналізу, яка дозволяє визначити межі та зміст проекту, відповівши відповіді на 6 питань: що включає ЗМІНИ, яка ПОТРЕБА, яке буде РІШЕННЯ, хто Стейкхолдери, яка очікувана ЦІННІСТЬ, який КОНТЕКСТ .

Канва бізнес-моделі та ланцюжок створення цінності;

CATWOE;

Аналіз стейкхолдерів;

Бенчмаркінг та аналіз ринку;

Причинно-наслідковий аналіз (діаграма Ісікави, метод 5Why);

Нотації моделювання бізнес-процесів (IDEF0, BPMN, EPC);

Аналіз бізнес-правил, зокрема. DMN моделі.

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

Як керувати вимогами в Agile середовищі?

Якщо ви створюєте продукт з нуля і ще не знаєте яким він повинен вийти, не витрачайте час на створення та підтримку BRD. Зазвичай такі проекти ведуться за методологією Agile.

Ось кілька рекомендацій які інструменти використовуються замість BRD в Agile середовищі та як організувати процес безперервного збору та реалізації вимог:

User Stories (Історії користувача): User Stories є ключовим інструментом для опису вимог в Agile-розробці. Вони представляють короткі описи вимог, сфокусовані на кінцевому користувачеві. User Stories формулюються у форматі "Як [користувач], я хочу [дія], щоб [мета]". та використовуються на плануванні ітерацій.

Backlog (Беклог): Белог є список вимог і завдань, які повинні бути виконані в проекті. Він складається з User Stories та інших типів вимог, пріоритизованих відповідно до бізнес-цінності та вимог замовника. Беклог постійно оновлюється і нові вимоги можуть бути додані або змінені в залежності від зворотного зв'язку та зміни пріоритетів.

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

Прототипи та експерименти: В Agile-розробці часто використовуються прототипи та експерименти для уточнення вимог та перевірки концепції продукту. Прототипи можуть бути створені для отримання зворотного зв'язку від замовника та перевірки відповідності очікуванням користувачів.

Документація за вимогами: Хоча в Agile-розробці не наголошується на великій документації, деякі вимоги та рішення можуть бути задокументовані у вигляді внутрішніх посібників, допоміжних документів або діаграм, щоб забезпечити краще розуміння вимог та сприяти комунікації в команді.

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

Модульність та інкрементальність: Замість повної специфікації вимог на початку проекту в Agile-розробці вимоги розробляються модульно та інкрементально. Команда фокусується на розробці та доставці невеликих, але робочих модулів функціональності, що дозволяє отримувати зворотний зв'язок та вносити корективи на ранніх етапах.

Регулярні перевірки та зворотний зв'язок: Agile-розробка передбачає регулярні перевірки та зворотний зв'язок для уточнення вимог та оцінки продукту. Замість того, щоб покладатися лише на документацію, команда та замовник взаємодіють протягом усього процесу розробки, що дозволяє коригувати вимоги та очікування.

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

Як створювати BRD документ?

Опишіть мету та очікувані результати проекту чи продукту.

Вкажіть зацікавлені сторони та їхні ролі.

Визначте контекст та область застосування проекту чи продукту.

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

Будьте конкретними: Сформулюйте цілі таким чином, щоб вони були конкретними, зрозумілими та вимірювальними. Використовуйте кількісні або якісні метрики, які дозволяють оцінити досягнення цілі. Наприклад, "Збільшити продаж на 20% протягом першого року після впровадження" або "Скоротити час відповіді на запити клієнтів з 48 годин до 24 годин".

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

Вкажіть контекст та очікування: Визначте контекст, у якому проект буде реалізовано, та очікування зацікавлених сторін. Вкажіть, які проблеми чи виклики мають бути вирішені, і які вигоди чи покращення очікуються. Наприклад, "Покращення досвіду користувача для підвищення рівня задоволеності клієнтів" або "Автоматизація процесів для зниження операційних витрат".

Виявіть довгострокові та короткострокові цілі: Різні цілі можуть мати різну тривалість та вплив. Вкажіть як короткострокові, так і довгострокові цілі проекту. Наприклад, короткострокова мета може бути досягнута протягом кількох місяців, тоді як довгострокова мета може бути пов'язана з довгостроковою стратегією компанії та досягнута протягом кількох років.

Зверніть увагу на цілі з бізнес-стратегією: Переконайтеся, що цілі проекту відповідають спільній бізнес-стратегії компанії або організації. Визначте, який проект вносить вклад у досягнення стратегії.

Опис поточної ситуації

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

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

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

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

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

Будьте специфічними та вимірювальним: Сформулюйте функціональні вимоги таким чином, щоб вони були специфічними, конкретними та  вимірювальним. Використовуйте кількісні або якісні метрики, щоб можна було визначити, чи виконані вимоги. Наприклад, "Система повинна підтримувати одночасну обробку 100 запитів" або "Форма реєстрації повинна містити поля для введення імені, адреси електронної пошти та пароля".

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

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

Врахуйте потреби та ролі користувачів: Ідентифікуйте різні ролі користувачів та опишіть їхні основні потреби та вимоги. Зверніть увагу, що різні користувачі можуть мати різні права доступу та функціональні можливості в системі.

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

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

Нефункціональні вимоги також повинні бути вимірювальними, щоб можна було оцінити, чи вони виконані. Визначте конкретні метрики або стандарти, які використовуватимуться для оцінки досягнення вимог. Наприклад, "Система повинна підтримувати час відгуку не більше 2 секунд для 95% запитів" або "Доступність системи повинна бути не менше 99,9% на рік".

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

Приділяйте увагу безпеці: Опишіть вимоги до безпеки системи, включаючи автентифікацію, авторизацію, захист даних, виявлення та запобігання вторгненням тощо. Зверніть увагу на відповідність законодавству та регулюючим стандартам, якщо вони застосовні.

Зверніть увагу на продуктивність: Опишіть вимоги до продуктивності системи, такі як максимальний час відгуку, пропускна здатність, використання ресурсів (пам'ять, процесор), ємність системи і т.д. Вкажіть граничні значення, які система повинна підтримувати під час навантаження.

Зверніть увагу на доступність: Опишіть вимоги щодо доступності системи, тобто час, протягом якого система має бути доступною для користувача. Вкажіть можливі вікна планового обслуговування або тимчасові обмеження.

Врахуйте зручність використання: Опишіть вимоги щодо зручності використання системи, інтерфейсу користувача, документації, посібників тощо.

Вимоги до даних

Вкажіть вимоги щодо зберігання, обробки та передачі даних.

Опишіть структуру та формати даних, а також вимоги щодо захисту інформації.

Ризики та обмеження

Ідентифікуйте потенційні ризики, пов'язані з проектом або продуктом, та запропонуйте заходи щодо їх управління.

Вкажіть обмеження та фактори, які можуть вплинути на виконання проекту.

План реалізації

Вкажіть етапи розробки та впровадження проекту чи продукту.

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

Вкажіть очікувані результати та критерії приймання для кожного етапу.

Оцінка проекту

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

Опишіть методи та механізми контролю якості проекту чи продукту.

Вкажіть очікувані вигоди та ROI (повернення інвестицій) від проекту чи продукту.

Програми

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

Узгодження та затвердження

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

Запитайте відгуки та коментарі, проведіть необхідні погодження та внесіть відповідні зміни.

Отримайте затвердження BRD від замовника чи уповноваженого представника.

Важливо пам'ятати, що структура та зміст BRD можуть змінюватись в залежності від конкретних вимог проекту або продукту. Рекомендується обговорити формат BRD із командою проекту або замовником, щоб переконатися, що всі необхідні аспекти будуть враховані.

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

Джерело:https://habr.com/ru/companies/otus/articles/734220/