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

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

1. Функціональні вимоги. Це перелік сервісів, які повинна виконувати система, причому повинно бути вказано, як система реагує на ті або інші вхідні дані, як вона поводиться в певних ситуаціях і т.д. В деяких випадках указується, що система не повинна робити.

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

3. Вимоги предметної області. Характеризують ту предметну область, де експлуатуватиметься система. Ці вимоги можуть бути функціональними і нефункціональними.

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

5.1.1. Функціональні вимоги

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

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

1. Користувач повинен мати нагоду проводити пошук необхідних йому книг н документів або по всій безлічі доступних каталожних баз даних або по певній їх підмножині.

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

3. Кожне замовлення повинне бути забезпечене унікальним ідентифікатором (ORDERІD), який копіюється у формуляр користувача для постійного зберігання.

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

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

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

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