• Рекомендації з управління нефункціональними вимогами

    Рекомендації з управління нефункціональними вимогами

Рекомендації з управління нефункціональними вимогами

Звичайно про вимоги. Бізнес аналітик, або особа, що виконує його функції, починає з визначення бізнес потреб, декомпозує їх на вимоги користувачів, а потім і на функціональні вимоги, разом із UX дизайнером та командою розробки перепрацьовує дизайни, рішення та приступає до його реалізації😃
Але чи нічого ми не забули?🤔

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

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

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

Є багато різновидів нефункціональних вимог, зокрема BABOK згадує 15, інші джерела можуть згадувати додаткові види📙
Проте, в залежності від предметної області, характеристик користувачів, пріоритети нефункціональних вимог для конкретного продукту можуть відрізнятися.

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

  • Доступність (Availability), в які проміжки часу система повинна бути доступна. Коли ви бачите напис на банкоматі 24/7 це і є характеристика доступності.
    Вона дуже залежить від предметної області та специфіки продукту: для внутрішніх корпоративних систем важливо, щоб вони функціонували в робочі години, в той час як для B2C продуктів цей показник буде значно вищий. Безумовно, гарантувати 100% доступність неможливо, тому важливі правильна оцінка сценаріїв використання зі сторони БА та зафіксовані очікування.
  • Швидкодія та навантаження (Performance & Load) характеризуються наскільки швидко система повинна виконувати функції, в тому числі враховуючи пікові навантаження.
    І тут це безумовно питання до бізнес аналітика, оскільки сам він повинен розуміти, коли і чому можуть виникати сплески активності, а також допомогти виразити їх у вимірювальних показниках🙌
  • Масштабування системи (Scalability).
    Кожен продукт менеджер хоче щоб продукт розвивався і його аудиторія збільшилася.
    Для того, щоб уможливити цей ріст на етапі проектування системи, бізнес аналітик повинен закласти можливість її масштабування, саме спробувати передбачити як змінюватиметься цількість користувачів системи, підключень до неї, інтеграції з нею, як змінюватиметься кількість операцій в системі з часом.
  • Локалізація (Localization).
    Чи потрібно в системі підтримувати локальні стандарти?
    Найпростіший приклад – підтримка системою декількох мов, проте, цей пункт можна розширити системою одиниць (метрична чи імперіальна) та підтримкою локальних стандартів в окремих галузях.
  • Сумісність (Compatability). З якими стандартами (технічними, галузевими, корпоративними) система повинна ефективно оперувати. Для прикладу, медичні системи повинні бути сумісними із стандартом обміну повідомленнями HL7.

Більше про ці та інші нефункціональні вимоги та не лише поговоримо на курсі Business Analysis: CBAP Exam preparation course👍

Дізнайтеся, що нового!
Ніякого спаму, ніколи!