Що таке нефункціональна вимога в розробці програмного забезпечення?

Автор: Чарльз Мур Чарльз Мур
Hours оновлений

⚡ Розумний підсумок

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

  • 📘 Визначення: Нефункціональна вимога, або NFR, описує, наскільки добре система працює з точки зору продуктивності, безпеки, зручності використання, надійності та портативності.
  • 🗂️ Поширені типи: Зручність використання, безпека, надійність, масштабованість, ємність, доступність, ремонтопридатність та відповідність нормативним вимогам – це категорії команд tracк найчастіше.
  • 📊 Модель FURPS+: FURPS+ групує NFR за функціональністю, зручністю використання, надійністю, продуктивністю, підтримкою та обмеженнями дизайну або інтерфейсу.
  • 🎯 Перевірювані твердження: Замініть слова «швидкий» або «безпечний» числовими порогами та методами перевірки, щоб NFR можна було протестувати та прийняти.
  • 🆚 Функціональний контраст: Функціональні вимоги вказують, що робить система; нефункціональні вимоги вказують, наскільки добре вона це виконує в реальних умовах.
  • ✅ Вплив на бізнес: Відсутність NFR є основною причиною виробничих інцидентів, регуляторних недоліків та дорогого перероблення архітектури на пізніх стадіях.
Детальніше

Нефункціональні вимоги в програмній інженерії

Що таке нефункціональна вимога?

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

Нефункціональні вимоги в програмній інженерії накладають обмеження на проектування системи в межах Agile Backlog. Наприклад, сайт повинен завантажуватися за три секунди, коли кількість одночасних користувачів перевищує 10 000. Опис нефункціональних вимог є таким же важливим, як і опис функціональних вимог.

Типи нефункціональних вимог

Основні категорії нефункціональних вимог:

Типи нефункціональних вимог

Типи нефункціональних вимог

  • Юзабіліті
  • Сервісне обслуговування
  • Керованість
  • Відновлюваність
  • Безпека
  • дані Integrity
  • Швидкість профілювання
  • доступність
  • масштабованість
  • Взаємодія
  • Надійність
  • Підтримка
  • Відповідність нормативам
  • Екологічні обмеження

Приклади нефункціональних вимог

Ось практичні приклади нефункціональних вимог:

  1. Користувачі повинні змінити початковий пароль після першого успішного входу в систему, і початковий пароль ніколи не можна використовувати повторно.
  2. Працівникам не дозволяється оновлювати власну інформацію про заробітну плату, і про будь-яку таку спробу необхідно повідомити адміністратора безпеки.
  3. Кожна невдала спроба користувача отримати доступ до елемента даних має бути зафіксована в журналі аудиту.
  4. Вебсайт повинен підтримувати 20 мільйонів одночасних користувачів без погіршення часу відгуку.
  5. Програмне забезпечення має бути портативним, щоб перехід з однієї операційної системи на іншу не створював проблем.
  6. Конфіденційність інформації, експорт обмежених технологій та права інтелектуальної власності повинні підлягати аудиту.

Функціональні та нефункціональні вимоги

Основні відмінності між функціональними та нефункціональними вимогами полягають у наступному:

Параметри Функціональні вимоги Нефункціональна вимога
Що це таке? дієслово Attributes
Вимога Це обов'язково Це не є обов'язковим
Тип захоплення Він фіксується у випадку використання. Це фіксується як атрибут якості.
Кінцевий результат Функція продукту Властивості продукту
захопивши Легко знімати Важко захопити
Мета Допомагає перевірити функціональність програмного забезпечення. Допомагає перевірити продуктивність програмного забезпечення.
Область фокусування Зосередьтеся на вимогах користувача Концентрується на очікуваннях користувача.
Документація Опишіть, що робить продукт Описує, як працює продукт
Тип тестування Функціональне тестування як-от системне, інтеграційне, комплексне, API-тестування тощо. Нефункціональне тестування, як-от тестування продуктивності, навантаження, зручності використання, безпеки тощо.
Виконання тесту Виконання тесту виконується перед нефункціональним тестуванням. Після функціонального тестування
Інформація про продукт Особливості товару: Властивості продукту

СТАТТІ ПО ТЕМІ

Переваги нефункціональних вимог

Основні переваги Нефункціональне тестування є:

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

Недоліки нефункціональних вимог

Поширеними недоліками нефункціональних вимог є:

  • Нефункціональні вимоги можуть впливати на кілька високорівневих програмних підсистем.
  • Вони потребують особливого розгляду під час архітектури та високорівневого проектування, що збільшує вартість.
  • Реалізація рідко зводиться до однієї програмної підсистеми.
  • Їх важко змінити після завершення етапу архітектури.

Модель FURPS+ для класифікації нефункціональних вимог

FURPS+ – це найпоширеніша таксономія для нефункціональних вимог. Спочатку розроблена в Hewlett-Packard, вона групує атрибути якості за п'ятьма основними категоріями плюс додаткові обмеження, позначені знаком «+». Модель допомагає бізнес-аналітикам уникнути пропуску цілого класу вимог.

  • Функціональні можливості: Можливості, безпека та можливість повторного використання, що виходять за рамки базового списку функцій.
  • Usability: Людський фактор, естетика, узгодженість, документація та адаптивність користувацького досвіду.
  • Надійність: Доступність, середній час між відмовами, відновлюваність, передбачуваність та точність.
  • Продуктивність: Швидкість, пропускна здатність, ємність, масштабованість та споживання ресурсів під навантаженням.
  • Підтримуваність: Тестованість, гнучкість, можливість встановлення, локалізація та ремонтопридатність поставленої системи.
  • Плюс (+): Проектування, реалізація, інтерфейс та фізичні обмеження, такі як необхідні платформи, стандарти або апаратне забезпечення.

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

Як писати тестовані нефункціональні вимоги

Добре написана нефункціональна вимога є вимірною, такою, що перевіряється, та обмеженою в часі. Розпливчасті твердження, такі як «система має бути швидкою» або «додаток має бути безпечним», є прагненнями, а не вимогами. Виконайте наведені нижче кроки, щоб перетворити намір на перевірений NFR.

  1. Визначте атрибут якості. Зіставте проблему з категорією FURPS+, щоб команда знала, чи це вимога щодо продуктивності, зручності використання, безпеки чи надійності.
  2. Виберіть метрику. Кожному NFR потрібна одиниця вимірювання — мілісекунди, запити за секунду, кількість одночасних користувачів, відсоток безвідмовної роботи або стандарт відповідності, такий як ISO 27001.
  3. Встановіть числове порогове значення. Замініть «швидкий» на «менше 400 мілісекунд на 95-му процентилі». Замініть «високодоступний» на «99.9 відсотка щомісячної безвідмовної роботи».
  4. Опишіть стан. Вкажіть навантаження, середовище або сегмент користувачів, до якого застосовується поріг, наприклад, «під час пікових продажів із 10 000 одночасних користувачів».
  5. Визначте метод перевірки. Зверніть увагу на тип тесту — навантажувальний тест, тест на проникнення, експеримент хаосу, аудит доступності — та інструмент, який підтвердить поріг.
  6. Застосуйте перевірку SMART. Переконайтеся, що вимога є Конкретною, Вимірною, Досяжною, Релевантною та Обмеженою в часі, перш ніж її помістити в чергу.

Приклад переписування: «Система має бути швидкою» стає «Сторінка оформлення замовлення має реагувати менш ніж за 500 мілісекунд на 95-му процентилі з 5,000 одночасними користувачами, що підтверджено JMeter «навантажувально тестувати кожен випуск». Переглянута заява дозволяє розробникам проектувати для неї, тестувальникам перевіряти її, а власникам продукту приймати її без заперечень.

Поширені запитання

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

Copilot та GPT перетворюють розпливчасті твердження про якість на вимірювані NFR за допомогою метрик, порогів, умов та методів перевірки. Бізнес-аналітики перевіряють кожен чернетку на відповідність категоріям FURPS+ та фреймворку SMART, перш ніж прийняти його до списку відкладених робіт.

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

Масштабованість, доступність, затримка, еластичність та економічна ефективність домінують у хмарних NFR. Команди також tracспостережуваність k, цілі аварійного відновлення, такі як RPO та RTO, а також відповідність вимогам кількох регіонів, оскільки вони визначають більшість рішень щодо хмарної архітектури.

Виберіть метрику з одиницею вимірювання, встановіть числове порогове значення, опишіть умову, за якої вона застосовується, та назвіть метод перевірки. Наприклад, час відгуку менше 400 мілісекунд на 95-му процентилі з 5,000 користувачами, перевірено JMeter.

Шифрування даних у стані спокою та під час передачі, стійкість автентифікації, авторизація на основі ролей, ведення журналу аудиту, тайм-аут сеансу та відповідність таким стандартам, як ISO 27001, PCI DSS та GDPR, – це NFR безпеки, які документує більшість команд.

Використання розпливчастих прикметників, пропуск метрики чи умови, перерахування NFR лише в кінці проєкту та копіювання шаблонних шаблонів, які жоден тест не може перевірити, – це найпоширеніші помилки, які призводять до переробки архітектури на пізніх стадіях.

NFR містяться у Специфікації вимог до програмного забезпечення, записах рішень щодо архітектури, угодах про рівень обслуговування та контрольних списках визначення виконання. Agile-команди часто додають вимірювані NFR до епічних етапів та визначення готовності для кожної користувацької історії.

Підсумуйте цей пост за допомогою: