BRD, FRD і SRS: який документ коли потрібен

Замовник підписує документ і вважає, що зафіксував, яким буде продукт. Команда читає той самий документ і бачить у ньому цілі: що ми взагалі хочемо змінити. Через місяць обидва вимовляють фрази «це ж було у вимогах» і «цього там ніколи не було» — про один і той самий файл.

BRD, FRD і SRS — три різних документи для трьох різних читачів і трьох різних моментів проєкту. BRD пояснює замовнику і спонсору, навіщо затівається зміна, і з’являється раніше за всіх, до того як вибрано рішення. FRD каже команді, що система має робити, і пишеться, коли рішення вже вибрано. SRS відповідає тим, хто будує й перевіряє: як саме це має працювати, щоб можна було реалізувати й написати тест. Це вся відповідь, далі — деталі.

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

Плутанина починається зі слова «бізнес-вимоги»

Найчастіша відповідь, яку я чую: «BRD — це бізнес-вимоги». Звучить логічно, літери збігаються. І це підміна, з якої росте все інше.

Бізнес-вимоги — це тип вимог. BRD — документ. У зводі знань BABOK вимоги діляться за типами: бізнес-вимоги (цілі й результати, заради яких затівається зміна), вимоги стейкхолдерів, вимоги до рішення — функціональні та нефункціональні — і перехідні, які потрібні лише на час переходу і після нього відмирають. Жодне з цих слів не називає файл. Це класифікація змісту: що саме ти записав, а не куди.

Далі стає видно, де пастка. Один документ спокійно містить кілька типів вимог одразу: у нормальному BRD поруч із цілями живуть вимоги стейкхолдерів, а в SRS разом із функціональними лежать нефункціональні. І навпаки, один тип вимог розмазується по трьох документах. Тому питання «в якому документі лежать бізнес-вимоги» не має єдиної відповіді, а питання «який документ відповідає на питання замовника, навіщо ми це робимо» — має.

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

Що каже стандарт — і чого він не каже

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

Міжнародний стандарт із роботи з вимогами — ISO/IEC/IEEE 29148

— справді описує документи вимог. У розділі 8 їх чотири: специфікація бізнес-вимог BRS, специфікація вимог стейкхолдерів StRS, специфікація системних вимог SyRS і специфікація вимог до програмного забезпечення SRS. Для кожного дано приклад структури.

Помічаєш, чого в цьому списку немає? BRD і FRD. Їх там немає взагалі.

Із трьох абревіатур, довкола яких іде суперечка, стандарту відома одна — SRS: її структура описана в розділі 8.5. А визначення стандарт дає сусідньому документу, системній специфікації вимог SyRS: структурований набір вимог — функцій, характеристик продуктивності, проєктних обмежень та інших атрибутів — до системи, її операційних середовищ і зовнішніх інтерфейсів. BRD і FRD — це галузева практика: назви, про які домовилися компанії та консалтинг, а не терміни зі зводу.

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

До речі, про «правильний шаблон SRS». Його часто беруть з IEEE 830 — документа 1998 року, за яким досі вчать на курсах. На сайті IEEE у цього стандарту статус Superseded: він замінений на ISO/IEC/IEEE 29148 ще в редакції 2011 року. Шаблон звідти не став поганим, але посилатися на нього як на чинний стандарт — помітна помилка.

Три документи за п’ятьма питаннями

Порівняльна таблиця «чим відрізняється» є у кожній другій статті, і користі з неї мало: вона відповідає на питання екзаменатора, а не на твоє. Тому розберемо кожен документ за п’ятьма питаннями, які виникають у роботі. П’яте — головне, його зазвичай не задають.

BRD

Хто пише: бізнес-аналітик разом із замовником або спонсором зміни. Хто читає: ті, хто дає гроші й ухвалює рішення «робимо чи ні». Яке рішення закриває: чи варто взагалі це затівати і як ми зрозуміємо, що вийшло. Коли з’являється: раніше за всіх, до вибору рішення. Якщо в документі вже названо систему, ви пишете не BRD. Чого немає без нього: критерію, за яким через пів року можна сказати, що проєкт удався. Без BRD успіх визначається настроєм замовника на демо, і сперечатися з цим нічим.

FRD

Хто пише: аналітик, уже знаючи, яке рішення вибрано. Хто читає: команда розробки й тестування, іноді — замовник, який хоче перевірити, що його зрозуміли. Яке рішення закриває: що система має робити, щоб цілі з BRD були досягнуті. Коли з’являється: після рішення про рішення, до оцінки трудовитрат. Чого немає без нього: меж обсягу робіт. Оцінка без FRD — це оцінка того, що кожен учасник зустрічі уявив собі сам, і розходження виявиться на прийманні.

SRS

Хто пише: аналітик разом із архітектором або розробником. Хто читає: ті, хто будує й перевіряє: розробка, тестування, інтегратори. Яке рішення закриває: як це має працювати, щоб це можна було реалізувати й перевірити. Коли з’являється: перед реалізацією і живе довше за два попередні — його оновлюють, поки система жива. Чого немає без нього: можливості написати тест-кейс, не звернувшись до автора. Кожна неоднозначність перетворюється на питання в чаті, а відповідь на нього ніде не зберігається.

П’ятий пункт — той самий, який відрізняє людину, яка документи вела, від людини, яка читала про них. «Що ламається, якщо цього документа немає» не можна вивчити, це видно лише з практики.

Два способи зіпсувати все це, які я бачу найчастіше

Документи розійшлися. Це відбувається не через лінощі. У документів різні читачі й різний темп життя: верхня частина змінюється на зустрічі із замовником, детальна — усередині спринту. Синхронізувати їх не зобов’язаний ніхто, поки не настане момент звірки. І тоді спливає справжня ціна — не переписування, а вирівнювання: потрібно заново з’ясувати, яка з версій правда, і зробити це може тільки той, хто пам’ятає обидва обговорення. Цієї роботи не видно в плані, вона не потрапляє ні в чию оцінку і з’їдає дні. Лікується вона не дисципліною, а зв’язками між документами — про те, як не губити вимогу по дорозі, є окремий розбір: матриця трасування вимог.

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

Документ без читача не марний — він шкідливий. Марний просто лежить. Цей виглядає як відповідь: на нього посилаються, за ним рахують терміни, за ним входять у проєкт новачки.

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

Який із них потрібен у твоїй ситуації

Вибирати варто не за стадією проєкту, а за питанням, на яке прямо зараз ніхто не може відповісти.

Незрозуміло, навіщо ми це робимо і як зрозуміємо, що вийшло, — потрібен BRD, навіть якщо він уміститься на сторінку. Зрозуміло навіщо, але кожен уявляє обсяг по-своєму — потрібен FRD. Обсяг зрозумілий, а тестувальник і розробник ходять до тебе з одними й тими самими питаннями — потрібен SRS. Усі три питання закриті, а документа немає жодного — можливо, він і не потрібен: команда з чотирьох людей, яка розмовляє щодня, не зобов’язана писати три специфікації.

Так ця відповідь і звучить на співбесіді переконливо: не «належить вести три документи», а «ось питання, яке не було закрите, тому ми завели ось це».

Як це звучить на співбесіді

У нашому банку питань із реальних співбесід тема цих трьох документів трапляється шість разів, і чотири з цих питань розмічені як junior. Це варто прочитати буквально: документи питають на вході в професію. Не «коли доростеш до Senior», а на першому ж інтерв’ю, де тебе питають про артефакти.

Слабка відповідь — перелічити розшифровки абревіатур. Вона формально правильна і закінчується нічим: співрозмовник киває і йде далі за списком.

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

Останнє відрізняє практика від переказу сильніше, ніж будь-які подробиці про структуру розділів.