3. Атестація вимог

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

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

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

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

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

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

Існує ряд методів атестації вимог, які можна використовувати спільно або кожен окремо.

1. Огляд вимог. Вимоги системно аналізуються рецензентами. Цей процес обговорюється в наступному розділі.

2. Прототипування. На цьому етапі прототип системи демонструється кінцевим користувачам і замовникові. Вони можуть експериментувати з цим прототипом, щоб переконатися, що він відповідає їх потребам.

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

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

Мал. 3. Автоматизований аналіз несуперечності вимог

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

Огляд вимог

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

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

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

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