Аналіз нефункціональних вимог (Non-Functional Requirements Analysis)

Zosym Maxym

Jan 27, 2023 • 4 min read

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

Аналіз нефункціональних вимог (Non-Functional Requirements Analysis) це одна з методик BABOK v3 (розділ 10.29).

Опис нефункціональних вимог в BABOK v3 (10.30.2)

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

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

Елементи нефункціональних вимог в BABOK v3 (10.30.3)

Категорії нефункціональних вимог (10.30.3.1)

До загальних категорій нефункціональних вимог відносяться наступні:

Доступність (Availability): ступінь, до якого рішення є працездатним і доступним, коли воно потрібне для використання, часто виражається у відсотках часу, протягом якого рішення є доступним.
Сумісність (Compatibility): ступінь, до якого рішення ефективно працює з іншими компонентами у своєму середовищі, наприклад, один процес з іншим.
Функціональність (Functionality): ступінь, до якого функції рішення відповідають потребам користувача, включаючи аспекти придатності, точності та інтероперабельності.
Придатність підтримки (Maintainability): легкість, з якою рішення або компонент може бути модифікований для виправлення помилок, покращення продуктивності або інших характеристик, або адаптації до зміненого середовища.
Ефективність роботи (Performance Efficiency): ступінь, до якого рішення або компонент виконує свої функції з мінімальним споживанням ресурсів. Може бути визначена на основі контексту або періоду, наприклад, пікове, середнє або непікове використання.
Переносимість (Portability): легкість, з якою рішення або компонент може бути перенесений з одного середовища в інше.
Надійність (Reliability): здатність рішення або компонента виконувати необхідні функції в заданих умовах протягом певного періоду часу, наприклад, середній час напрацювання на відмову пристрою.
Масштабованість (Scalability): ступінь, з яким рішення здатне рости або розвиватися для виконання зростаючих обсягів роботи.
Безпека (Security): аспекти рішення, які захищають вміст рішення або його компоненти від випадкового або зловмисного доступу, використання, модифікації, знищення або розкриття.
Зручність використання (Usability): легкість, з якою користувач може навчитися користуватися рішенням. Сертифікація: обмеження на рішення, які необхідні для відповідності певним стандартам або галузевим конвенціям.
Відповідність (Compliance): регуляторні, фінансові або юридичні обмеження, які можуть відрізнятися залежно від контексту або юрисдикції.
Локалізація (Localization): вимоги, пов'язані з місцевими мовами, законами, валютами, культурою, правописом та іншими особливостями користувачів, що вимагає уваги до контексту.
Угоди про рівень обслуговування (Service Level Agreements): обмеження організації, що обслуговується рішенням, які офіційно узгоджені як постачальником, так і користувачем рішення.
Розширюваність (Extensibility): здатність рішення включати нову функціональність.

Вимірювання нефункціональних вимог (10.30.3.2)

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

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

Наприклад:

"Процес має бути простим у вивченні" може бути виражено як "90% операторів повинні бути здатні використовувати новий процес після не більше ніж шести годин навчання", і
"Система повинна швидко реагувати" може бути виражена як "Система повинна надавати 90% відповідей не більше ніж за дві секунди".

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

Наприклад:

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

Контекст нефункціональних вимог (10.30.3.3)

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

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

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

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

Міркування щодо використання нефункціональних вимог в BABOK v3 (10.30.4)

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

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

Обмеження нефункціональних вимог

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