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

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

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

Разом з тим нефункціональні вимоги можуть відноситися не тільки до самої програмної системи: одні можуть відноситися до технологічного процесу створення ПЗ, інші - містити перелік стандартів якості, що накладаються на процес розробки. Крім того, в специфікації нефункціональних вимог може бути вказано, що проектування системи повинне виконуватися тільки певними CASE-засобами, і приведено опис процесу проектування, якому необхідно слідувати.

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

В сі нефункціональні вимоги, показані на мал. 5.2, розбиті на три великі групи.

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

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

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

У

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

Вимоги до продукту

Всі взаємодії між інтерфейсом APSE і користувачем здійснюються на основі стандартної множини символів мови Ada.

Організаційні вимоги

Розробка системи і створення супутньої документації виконуються на основі стандарту XYZCo-SP-STAN-95.

Зовнішні вимоги

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

врізці 5.1 приведений приклад вимог до продукту, організаційних і зовнішніх вимог. Вимоги до продукту пов'язані з середовищем програмування APSE для мови Ada. Це обмежує свободу проектувальника системи у виборі символів - можна використовувати тільки символи з призначеного для користувача інтерфейсу APSE. Організаційні вимоги указують, що система повинна розроблятися згідно внутрішньому стандарту компанії на розробку ПЗ, що має код XYZCo-SP-STAN-95. Зовнішні вимоги витікають з необхідності дотримання законодавства про збереження конфіденційності. Внаслідок цього системні оператори не матимуть доступу до тих даних, які їм не потрібні для роботи з системою.

О

Врізка 5.2. Системні цілі і перевірка вимог

Системна ціль

Система повинна бути простою в експлуатації для досвідченого оператора і зводити кількість його помилок до мінімуму.

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

Досвідченому оператору повинні бути доступні всі системні функції після 2 годин навчання роботі. Після навчання середня кількість помилок оператора не повинна перевищувати двох за робочий день.

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

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

На практиці виразити нефункціональні вимоги за допомогою кількісних показників важко. Часто замовник ПЗ не може оформити своє бачення майбутньої системи за допомогою вимог, виражених кількісними показниками. Або деякі системні вимоги, наприклад зручність супроводу, взагалі не можна виразити через кількісні показники. Крім того, витрати на об'єктивне вимірювання кількісних нефункціональних вимог можуть виявитися украй високими. Тому часто документ, що специфікує вимоги до системи, містить опис системних цілей спільно з чітко сформульованими вимогами. Ці системні цілі корисні, оскільки відображають уявлення (і пріоритети) замовника про майбутню систему. Разом з тим замовник повинен розуміти, що його системні цілі можуть потрактувати різними способами і їх неможливо об'єктивно проконтролювати.

Таблиця 5.2. Кількісні показники для нефункціональних вимог

Показник	Одиниці вимірювання
Швидкість	Кількість виконаних транзакцій в секунду; час реакції на дії користувача; час оновлення екрану
Розмір	Кілобайти; кількість модулів пам'яті
Простота експлуатації	Час навчання персоналу; кількість статі в довідковій системі
Надійність	Середня тривалість часу між двома послідовними проявами помилок в системі; вірогідність виходу системи з ладу; коефіцієнт готовності системи
Стійкість до збоїв	Час відновлення системи після збою; відсоток подій, що приводять до збоїв; вірогідність псування даних при збоях
Переносимість	Відсоток машинно-залежних операторів; кількість машинно-залежних підсистем

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

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