Вимоги не формуються самостійно. Застосовуйте ці 16 практик для ефективного збору та аналізу вимог.
Три основні класи вимог до програмного забезпечення – бізнес-вимоги(business requirements), користувацькі вимоги(user requirements) та вимоги до рішення (solution/functional requirements) – надходять з численних джерел у різний час проєкту. Різні типи інформації стосуються різної аудиторії та цілей, тому їх потрібно документувати по-різному.
Ось ці 16 практик, які бізнес-аналітик (BA), власник продукту (PO), продуктовий менеджер (PM) або інженер з вимог (Requirements engineer) можуть використовувати для отримання інформації, яка потрібна команді розробників для створення правильного продукту.
Ви не будете використовувати всі ці методи в кожному проєкті, але ними потрібно володіти, щоб мати змогу використати правильний метод у конкретній ситуації. Мені цікаво, які з цих чи інших практик – ви вважаєте найважливішими та найціннішими. Будь ласка, поділіться своїм досвідом у відповідях.
1.Визначте бізнес-вимоги(business requirements).
Документ Vision and Scope містить містить бізнес-вимоги до продукту, включно з бізнес-цілями, обмеженнями тощо. Бізнес-цілі допомагають команді залишатися сфокусованою на досягненні корисного результату. Бачення продукту (vision statement) дає всім зацікавленим сторонам спільне розуміння і концентрує увагу на рішенні, яке розробляється командою. Обсяг (scope) визначає межу між тим, що входить і що не входить у певний реліз або ітерацію розробки.
2.Визначте групи зацікавлених сторін (стейкхолдерів).
Інтереси всіх зацікавлених сторін перетинаються у вимогах до продукту. Зацікавлена сторона (стейкхолдер) – це будь-яка особа або група осіб, які беруть активну участь у проєкті, зазнають впливу від проєкту або можуть впливати на його напрямок. Ще на ранній стадії команда повинна визначити потенційні групи зацікавлених сторін і зрозуміти їхній вплив на роботу, очікування, занепокоєння, побоювання, вимоги та обмеження.
3.Визначте класи користувачів та їхні характеристики.
Щоб не упустити потреби жодної групи зацікавлених сторін, визначте різні групи користувачів вашого продукту. Вони можуть відрізнятися за частотою використання, функціями, рівнями привілеїв, досвідом або іншим чином. Опишіть особливості їхніх робочих завдань, ставлення, місцезнаходження або особисті характеристики, які можуть вплинути на дизайн продукту (проєктування продукту). Якщо немає змоги залучити реальних користувачів, user personas – описи уявних персонажів, які представлятимуть певні класи користувачів.
4.Визначте відповідальних осіб, які приймають рішення щодо вимог
Кожна команда розробників постійно стикається з необхідністю приймати рішення щодо вимог:вирішувати конфлікти між вимогами, динамічно пріоритизувати елементи беклогу, робити компромісні рішення(trade-off decisions), обробляти запити на зміни (change requests) та коригувати обсяг робіт(scope). Визначте відповідних і уповноважених осіб для прийняття кожного класу рішень. Кожна група, що приймає рішення, також повинна вибрати відповідне правило прийняття рішень, щоб дійти висновків.
5.Виберіть представника продукту для кожного класу користувачів.
Визначте особу, яка зможе точно виступати в ролі безпосереднього голосу замовника для кожного класу користувачів. Представник продукту відстоює потреби відповідного класу користувачів і приймає рішення від їхнього імені. Найпростіше це зробити у випадку розробки внутрішніх інформаційних систем, де користувачами є ваші колеги. Для комерційних продуктів використовуйте наявні відносини з ключовими клієнтами або бета-тестувальними платформами, щоб знайти відповідних представників продукту.
6.Співпрацюйте з представниками користувачів, щоб визначити їхні вимоги.
Разом з представниками користувачів визначте завдання, які вони повинні виконувати за допомогою рішення, і цінність, яку вони прагнуть отримати. Вимоги користувачів можуть бути представлені у формі варіантів використання (use cases), user stories або сценаріїв. Намагайтеся зрозуміти взаємодію між користувачами та рішенням, яка дозволить їм успішно виконати кожне завдання.
7.Визначте події системи та реакції на них
Складіть список зовнішніх подій, які система може виявити, та очікуваних реакцій на кожну подію.
- Сигнальні події — контрольні сигнали або дані від апаратних пристроїв чи інших систем.
- Часові події (temporal) — тригерують реакцію у певний час або після визначеного інтервалу, наприклад, щоденне формування зовнішнього звіту системою.
- Бізнес-події часто запускають use cases.
8.Проведіть інтерв’ю для з’ясувння вимог.
Бізнес-аналітик може проводити інтерв’ю в форматі один-на-один або з невеликою групою зацікавлених сторін. Інтерв’ю є ефективним способом з’ясування вимог, який не займає надто багато часу у стейкхолдерів, оскільки на зустрічі обговорюються лише їхні конкретні вимоги. У разі виникнення суперечливих вимог вам може знадобитися провести груповий воркшоп для їх узгодження.
9.Проводьте фасилітовані воркшопи з виявлення вимог
Воркшопи зі збору вимог, які дозволяють бізнес-аналітикам співпрацювати із замовникам, є потужним інструментом для дослідження потреб користувачів і формулювання початкових варіантів вимог. Для досягнення результативності і продуктивності воркшопів важливо фасилітувати їх за чітко визначеним планом.
10.Проводьте фокус-групи з типовими користувачами.
Збирайте групи представників користувачів попередніх або схожих продуктів, щоб отримати їхню думку щодо функціональності та якості продукту. Фокус-групи особливо цінні у розробці комерційних продуктів, для яких ви можете мати велику та різноманітну базу клієнтів.
11.Спостерігайте за роботою користувачів.
Спостереження за тим, як користувачі виконують свої завдання, допомагає зрозуміти контекст для потенційного використання ними нового рішення. У процесі спостереження ви можете дізнатися про рішення, які вони приймають, та дії, які виконують, але про які вони, можливо, не здогадалися б розповісти під час інтерв’ю. Процесні або swim lane діаграми допомагають візуалізувати ці кроки та рішення і, таким чином, показати взаємодію різних компонентів, що розкриє вимоги до рішення, яке має підтримувати цей процес.
12.Поширюйте опитування.
Опитування – ефективний інструментом для збору думок різних груп користувачів з метою визначення їхніх потреб. Опитування корисні для великих груп користувачів, особливо для розподілених груп. На основі отриманих результатів ви можете спрямувати подальші зусилля на деталізацію вимог там, де це найбільш актуально. Порада: завжди тестуйте опитування перед його поширенням, щоб переконатися, що поставлені запитання зрозумілі й не містять неоднозначності.
13.Аналізуйте системи та інтерфейси користувачів
Для кожної системи, що взаємодіє з вашою, визначте функціональність, яка може породити вимоги для вашого рішення. Це може описувати:
- які дані передавати,
- які дані отримувати,
- правила щодо даних (наприклад, критерії валідації).
Ви також можете виявити існуючу функціональність, яку вам не доведеться реалізовувати у вашому рішенні. Якщо ви маєте існуючий продукт як взірець, наприклад, у випадку заміни застарілої програми, проаналізуйте його користувацький інтерфейс, щоб виявити інформацію про вимоги користувачів і функціональні потреби, які він задовольняє.
14.Аналізуйте документацію
Існуюча документація описує, як система працює на даний момент або що вона повинна робити. До документації належать :
- будь-які письмові матеріали про поточні системи, бізнес-процеси, специфікації вимог,
- дослідження конкурентів,
- інструкції користувача COTS (commercial off-the-shelf,комерційного ПО).
Аналіз таких документів може дати уявлення про те, як люди наразі виконують свої завдання, яка функціональність має залишитися, яка функціональність не використовується, а також які можливості пропонують конкуренти.
15.Аналізуйте звіти про проблеми в поточних системах для генерації ідей щодо вимог.
Звіти про проблеми та запити на покращення від користувачів є цінним джерелом ідей для функцій, які можуть бути включені в майбутній реліз або новий продукт. Співробітники служби підтримки та технічного обслуговування можуть надати корисну інформацію для формулювання вимог до майбутньої розробки.
16.Повторне використання існуючих вимог
Якщо стейкхолдери запитують функціональність, схожу на ту, що вже існує в іншому продукті, перевірте, чи можна повторно використати або адаптувати існуючі програмні компоненти. У проєктах часто можна повторно використовувати вимоги, які відповідають бізнес-правилам організації, наприклад, вимоги до безпеки та доступності. Інші приклади успішного повторного використання включають глосарії (словники, glossaries), моделі даних та їх визначення, профілі стейкхолдерів, описи класів користувачів і перcонажі (personas).
З урахуванням цих можливостей досвідчений бізнес-аналітик повинен визначити, які з них будуть найефективнішими та найдоцільнішими для конкретного продукту.
Наведена нижче таблиця може допомогти у цьому.
Оберіть рядок(ки), які відповідають вашому проєкту, і, читаючи зліва на право, визначте, які техніки збору вимог є найбільш корисними (позначені “X”). Наприклад, якщо ви розробляєте новий застосунок, розгляньте комбінацію інтерв’ю зі стейкхолдерами, воркшопів і аналізу інтерфейсу системи.
Рекомендовані техніки збору вимог залежно від характеристик проєкту
З’ясування вимог – це не просто процес “збирання вимог” або опитування випадкових користувачів: “Що вам потрібно?” і записування їхніх відповідей. Збір вимог включає систематичний процес дослідження, вивчення, відкриття та створення нових рішень. Спробуйте обдумано застосувати ці техніки у вашому проєкті й перевірте, чи здобудете Ви більше знань і розуміння, ніж могли б за інших обставин.
Оригінальна стаття – 16 Good Practices for Requirements Elicitation, переклад – Анастасія Кравець, ревью – Іван Вільчавський. Оригінальне фото з статті.