Види і властивості вимог

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

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

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

Сформулюємо ряд важливих властивостей вимог.

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

· Повнота і несуперечність.

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

· Прослежіваємість — важливо бачити те або інша вимога в різних моделях, документах, нарешті, в коді системи. А то часто виникають питання типу – "Хто знає, чому ми вирішили, що такий-то модуль повинен працювати таким чином..?". Прослежіваємость функціональних вимог досягається шляхом їх дроблення на окремі, елементарні вимоги, привласнення ним ідентифікаторів і створення моделі трасування, яка в ідеалі повинна протягуватися до програмного коду. Хочеться наприклад, знати, де потрібно змінити код, якщо дана вимога змінилася. На практиці повна формальна прослеживаемость труднодостижима, оскільки логіка і структура реалізації системи можуть сильно не співпадати з такими для моделі вимог. У результаті одна вимога виявляється сильно "розмазало" за кодом, а та або інша ділянка коду може впливати на багато вимог. Але прагнути до прослеживаемости необхідно, розумно суміщаючи формальні і неформальні підходи.

· Тестіруємость і проверяемость — необхідно, щоб існували способи відтестувати і перевірити дану вимогу. Причому, важливо обидва аспекти, оскільки часто проверить-то замовник може, а ось тестувати дану вимогу дуже важко або неможливо з причини обмеженості доступу (наприклад, з міркувань безпеки) до оточення системи для команди розробника. Отже, необхідні процедури перевірки – выполнение тестів, проведення інспекцій, проведення формальної верифікації частини вимог і ін. Потрібно також визначати "планку" якості (чим вище якість, тим воно дорожче стоїть!), а також критерії повноти перевірок, щоб що виконують їх і керівники проекту чітко усвідомлювали, що саме перевірене, а що ще немає.

· Модифікується. Визначає процедури внесення змін у вимоги.