6.3 Затвердження моделі (Model Validation)

Затвердження або атестація моделі пов'язана з питаннями забезпечення прийнятної якості продукту. Впевненість у відповідності моделі заданим вимогам може бути закріплена формально з боку користувачів/замовника. У той же час, перевірка і атестація моделі, наприклад, об'єктно-орієнтованого зображення бізнес-сутностей і зв'язків між ними може бути перевірена з тим або іншим ступенем використання формальних методів, наприклад, статичного аналізу (пошук зв'язків та шляхів взаємодії між описаними об'єктами і виділення різного роду невідповідностей). Це - інша сторона затвердження моделі.

6.4 Приймальні тести (Acceptance Tests)

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

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

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

Додаткова інформація, пов'язана з приймальними тестами представлена ​​в галузі знань SWEBOK "Тестування програмного забезпечення" (Software Testing) в описі 2.2.4 "Тести відповідності" (Conformance testing).

 

7. Практичні переконання (Practical Considerations)

 

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

Далеко не кожна організація має культуру документування та управління вимогами. Особливо часто це зустрічається в молодих невеликих компаніях, які виводять на ринок нові продукти і володіють "сильним vision-ом", чітким розумінням цілей, для яких створюється продукт, але не мають достатньо ресурсів і, багато в чому тому що вважають, що динамізм - запорука успіху. Поступово такі компанії виростають, проекти - ускладнюються і, як наслідок складається ситуація, коли відстежити всі необхідні вимоги в неформальній формі вже просто неможливо. Ця тема практично невичерпна. Багато середніх за масштабами компаній намагаються зберегти той же рівень гнучкості і динамізму, який застосовувався в часи народження компанії, коли вона ще була "стартапом" (start-up - назва молодих компаній, які розкручували свої проекти за часів інтернет-буму кінця 90-х і яке прижилося для новоутворюваних малих бізнесів, що ростуть не стільки на зовнішніх інвестиціях, скільки на ідеях і завзятості її творців). Так чи інакше, динамізм притаманний не тільки компаніям, але й продуктам, самим вимогам до них. Управління змінами, концепцією, баченням продукту не може бути хаотичним - історія індустрії однозначно це доказує. Тому ставлення до управління вимогами як до постійно діючого бізнес-процесу - абсолютно обгрунтований підхід, що вимагає застосування певних практик. В іншому випадку, ми практично гарантовано зіткнемося із вкрай негативними наслідками, які не раз описувалися і згадувалися вище.