Вимоги не розкидані навколо в очікуванні, коли бізнес-аналітик збере їх. Виявлення вимог (requirements elicitation) – більш точний термін.
Люди часто говорять про збір вимог до програмного проєкту, але це створює неточне враження. Слово “збір” означає, що вимоги десь лежать і чекають на бізнес-аналітика (БA) або власника продукту, щоб їх зібрати. Коли я чую, як хтось говорить “збирати вимоги”, у моїй уяві виникає образ збирання квітів чи полювання за великодніми крашанками. Це не так просто.
Збирання versus виявлення
Вимоги рідко існують повністю сформованими у свідомості користувачів, готовими до передачі БA або команді розробників на перший запит. Збір вимог передбачає збір інформації, але він також включає в себе дослідження та винахідництво. Термін “виявлення вимог” (requirements elicitation) точніше передає, як розробники програмного забезпечення співпрацюють із зацікавленими сторонами, щоб дослідити можливості майбутнього рішення.
У словнику слово “elicitation” означає “викликати”, “витягати” або “провокувати”. Бізнес-аналітики не намагаються спровокувати стейкхолдерів, хоча іноді це трапляється ненавмисно. Важливою частиною функції БA під час виявлення вимог є постановка запитань, щоб стимулювати мислення стейкхолдерів і вийти за межі поверхневого та очевидного. Найменш корисні запитання при дослідженні вимог – “Чого б ви хотіли?” і “Які ваші вимоги?” Відповіддю на такі нечіткі запитання є багато випадкових, хоча й важливих даних, змішаних зі сторонньою інформацією та приправлених невисловленими припущеннями.
Коли виявляти вимоги
Виявлення вимог вимагає ітеративного та інкрементального підходу з циклами удосконалення, уточнення та коригування. Обговорення може рухатися від нечітких, високорівневих концепцій до деталей, або ж починатися з конкретних фрагментів функціональності, які БA повинен потім синтезувати на більш високому рівні абстракції. Інформація від одного джерела може конфліктувати з інформацією від іншого.
Іноді БA отримує нові дані, які змушують переглянути ті питання, які команда вважала вирішеними. Подібні повернення можуть розчарувати учасників (“Хіба ми вже не говорили про це?”), але така природа людської комунікації та дослідження. Виявляти вимоги – це як чистити цибулину і відкривати її внутрішню частину, за винятком того, що чим більше ви очищаєте, тим більшою стає цибулина.
У гіпотетичній моделі водоспаду (waterfall life cycle) в чистому вигляді виявлення вимог здійснюється лише на початку проєкту. Існують проєкти, для яких працює такий підхід, але вони витрачають значну кількість часу на фазу збору вимог. Навіть команди традиційних проєктів знають, що вимоги, написані на ранній стадії, повинні переглядатися та уточнюватися протягом усього проєкту.
На проєктах гнучкої методології вимоги виконують невеликими частинами і очікують, що набір вимог буде рости і розвиватися під час розробки. Кожна ітерація розробки включає завдання з виявлення вимог. Проєкт починається з вивчення вимог, але на цьому етапі не очікується отримання повного та детального розуміння. Натомість, команда акумулює достатньо знань для пріоритезації та розподілу вимог для ранніх ітерацій розробки. Під час кожної ітерації команда вдосконалює свої користувацькі історії та критерії приймання до того рівня деталізації, який потрібен розробникам і тестувальникам.
Контекст виявлення вимог
Бізнес-вимоги проєкту створюють підґрунтя для виявлення вимог. Вони визначають бізнес-цілі проєкту, обсяг – що буде включено, та обмеження – що не буде включено. Для початку, ідентифікуйте стейкхолдерів, які можуть бути цінними джерелами інформації. Ці стейкхолдери можуть мати право вето щодо вимог (“Ви не можете цього робити”) або право додати вимогу (“Ви повинні також зробити ось це”).
Якщо ви бізнес-аналітик, сплануйте стратегію виявлення вимог заздалегідь. Обрані техніки взаємодії залежатимуть від того, який доступ ви маєте до стейкхолдерів, наскільки їх багато, де вони знаходяться і скільки часу вони можуть витратити.
До теми – 5 кращих практик із виявлення прихованих потреб замовника.
Техніки виявлення вимог
Нижче наведено кілька методів виявлення вимог, які можуть бути корисними для більшості проєктів.
Інтерв’ю. Індивідуальні інтерв’ю зі стейкхолдерами є ефективними та сфокусованими. Однак їм бракує синергетичної взаємодії, яка часто стимулює нові ідеї в групових дискусіях. БA повинен заздалегідь підготувати список сфер, які потрібно дослідити, і запитань, як для індивідуальних інтерв’ю, так і для групових воркшопів.
Групові воркшопи. Воркшопи, де БA зустрічається з кількома представниками користувачів та іншими стейкхолдерами, є поширеною практикою виявлення вимог. На воркшопах зазвичай досліджують вимоги користувачів, щоб зрозуміти, які завдання система повинна дозволяти їм виконувати. Група легко може “провалитися в щурячу нору”, загрузнувши в деталях, коли потрібно мислити на більш високому рівні. Досвідчений фасилітатор стежить за дотриманням учасниками теми та цілей дня.
Спостереження. Спостерігаючи за користувачами під час роботи, можна отримати інформацію, якою вони, можливо, не подумають ділитися, якщо БA просто запитає їх, чим вони займаються. Аналітик-спостерігач може виявити проблеми та вузькі місця, які може усунути запропоноване рішення, щоб зробити бізнес-процеси більш ефективними. Користувачі часто використовують обхідні шляхи, щоб компенсувати недоліки програмної системи, тому спостереження може виявити поліпшення, які можна внести в систему на заміну.
Аналіз документів. Документація існуючих систем, продуктів та бізнес-процесів може бути багатим джерелом потенційних вимог. Вивчення такої документації допомагає БA швидко зорієнтуватися в новій галузі. Такий аналіз часто може надати інформацію про відповідні бізнес-правила: корпоративну політику, державні норми та галузеві стандарти. Інформація, отримана з історичних джерел, потребує перевірки, щоб переконатися, що вона все ще актуальна.
Опитування. На індивідуальні інтерв’ю та воркшопи можна залучити лише обмежену кількість учасників. Опитування дають змогу з’ясувати думку та ставлення до поточних продуктів більшої кількості людей. Онлайн опитування корисні для комерційних продуктів, коли команда розробки не має прямого доступу до репрезентативних користувачів. Створювати опитування, які виявляють потрібну інформацію та підвищувати ймовірність того, що користувачі заповнять їх, – це ціле мистецтво.
Вікі. Вікі та інші інструменти для спільної роботи дозволяють збирати інформацію та ідеї від більшої кількості людей, ніж можна було б зібрати на воркшопі. Допис однієї людини спонукає іншу до схвалення, редагування, розширення або незгоди. Недоліком такого вільного підходу є те, що аналітик повинен фільтрувати потоки дискусій у пошуках цінних знань.
Прототипи. Людям важко уявити, яким може бути запропоноване рішення, виходячи з абстрактних обговорень і списків вимог. Прототип робить вимоги більш матеріальними. Навіть прості ескізи екранів можуть допомогти учасникам воркшопу кристалізувати своє мислення. Якщо ви створите прототипи надто рано під час дослідження вимог, люди можуть зациклитися на конкретному – можливо, неідеальному – рішенні.
Закладання основи
Виявлення вимог – це основна практика інженерії вимог у проєктах розробки програмного забезпечення та систем. Без міцного фундаменту знань про вимоги, отриманих шляхом ефективного виявлення потреб, будь-який проєкт стоїть на хиткому ґрунті.
Оригінальна стаття People don’t simply gather requirements, переклад – Марія Слободян, ревью – Іван Вільчавський, фото від Cameron Ahlverts з сайту Unsplash.