top of page

BA Q&A: Типи запитів на зміну вимог

Оновлено: 16 січ. 2023 р.

Вирішив публікувати деякі запитання та відповіді, які обговорюємо на «Комплексному онлайн тренінгу з бізнес-аналізу»

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

Відповідь: По-перше нам треба зрозуміти, для чого ми використовуємо цю класифікацію. Це може бути обумовлено особливостями контракту: запит на зміну сплачується з одного бюджету, запит на новий функціонал з другого, розширення – з третього. Або ми хочемо зрозуміти, наскільки якісно бізнес-аналітик здійснив виявлення вимог, припускаючи, що запит на зміну=неякісне виявлення вимог. Але зрозуміло, що це не завжди так. Вимоги можуть змінюватись не з вини БА, а значить при фіксації запиту на зміну нам буде потрібно додатково визначити атрибут «Причина зміни». В будь-якому випадку класифікація має бути чимось викликана, окрім здорової цікавості.

Давайте розглянемо три типи - запит на зміну, нова вимог та розширення існуючої вимоги – через приклади.

Запит на зміну

  • Поле «Х» було обов’язковим, має стати необов’язковим

  • Змінити розміщення елементів на інтерфейсі

  • Значення атрибуту «Х» у звіті обраховувалось за формулою Ф1, має розраховуватись за формулою Ф2.

Отже, система вже певним чином щось робить, є вимога, щоб вона робила це по іншому. В нас є оригінальна вимога, запит її змінює. Було б непогано їх пов’язати між собою (трасування).

Нова вимога

  • Додати новий звіт

  • Створити новийAPI

  • Додати нову функцію для користувача

Щоб зрозуміти, що мова йде про нову вимогу, ми маємо заздалегідь визначити початкові границі. Це може бути ТЗ, Бачення системи, Дорожня карта тощо. Якщо в нас є початковий перелік передбаченої функціональності, ми можемо класифікувати запит як «Нова функціональність». Тобто ми хочемо додати нову відносно складну поведінку (набір сценаріїв), яка початково не передбачалась.

Розширення існуючої вимоги

  • Додати нову перевірку при створенні/редагуванні сутності

  • Додати новий стовпчик в звіт

  • Додати новий атрибут на форму

  • Автоматично визначати значення атрибуту Х при заповненні форми

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

Цікаве питання щодо змін/додавання нефункціональних вимог. Наприклад, є в нас функція побудови звіти. Нікому не спало на думку визначити вимоги щодо швидкодії. І ось з’являється нова вимога «Звіт має будуватись не довше 5 секунд». Або в нас була вимога «Звіт має будуватись не довше 10 секунд», а тепер є бажання зменшити цей час до 5 секунд. В другому випадку – це запит на зміну або розширення існуючої вимоги. В першому випадку – це пропущена вимога, звіт вже існує, отже і це запит на зміну. Але погодьтеся, що це дуже різні запити на зміни 😊 Розклад тренінгів з бізнес-аналізу та аналізу даних від Art of Business Analysis

577 переглядів0 коментарів

コメント


bottom of page