Сценарії.

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

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

Сценарій починається з загального опису, потім поступово деталізується для створення повного опису взаємодії користувача з системою. У більшості випадків сценарій включає наступне.

1. Опис стану системи на початку сценарію .

2. Опис нормального протікання подій.

3. Опис виняткових ситуацій і способів їх обробки.

4. Інформацію щодо інших дій , які можна здійснювати під час виконання сценарію.

5. Опис стану системи після завершення сценарію.

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

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

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

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

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

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

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

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

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

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

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

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

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

Огляд вимог

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

Огляд вимог може бути неформальним і формальним.

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

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

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