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

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

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

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

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

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

• Повнота і несуперечливість.

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

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

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

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