18.04.2012 Перевірка вимог

• Проблемні ситуації процесу формування і оцінки вимог;

• Методи і засоби перевірки вимог.

Властивості коректних вимог

Як здійснити перевірку готової системи (або її процесу створення)?

1. Впевнитись, що система відповідає сформульованим вимогам

2. Впевнитись, що система дійсно працює

Вимоги повинні задовольняти наступним властивостям: повноті, ясності, коректності, узгоджуваності, перевіряємості і т.д.

Крім того варто впевнитись в тому, що :

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

2. Вимоги до ПЗ точно відображають системні вимоги, бізнес-правила.

3. Вимоги забезпечують якісну основу для проектування і збірки ПЗ.

Проблемні ситуації:

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

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

3. Мінімальна специфікація – представлення вимог на 2-3 сторінках (у невеликих проектах). Мінімальне спека доречна, якщо має місце наявність одночасно трьох обставин:

   1. Ціна контракту і розміри проекту настільки малі, що розробляти повну спеку є дорогим задоволенням.

   2. Колектив розробника володіє достатнім ступенем досвіду виконання проектів у суміжних областях

   3. Між замовником та розробником існують конструктивні відносини і обидві сторони розуміють і приймають ризики міні-специфікації.

Методи і засоби перевірки вимог розрізняють за параметрами:

1. За широтою аналізу – перегляд (вибіркова перевірка)

2. За ступенем формалізації – неофіційні процедури, процедури, що проводяться за формальними правилами (інспекції, експертизи).

3. За складом групи перевірки – з (без) участю автора, з (без) участі менеджера проекту, з (без) участю представників зовнішніх організацій.

4. За використовуваними засобами – тексти вимог, тестові сценарії, критерії прийнятності, прототип.

Неофіційні перегляди вимог:

1. Перегляди «за столом» (коли перевірку робить колега по роботі)

2. Колективна перевірка (коли запрошується декілька колег для паралельної перевірки продукту)

3. Критичний аналіз (автор описує створюваний продукт і просить його прокоментувати).

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

Офіційна перевірка вимог:

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

Головний результат – сукупність усіх знайдених дефектів і піднятих питань.

Експертиза як метод перевірки вимог (інспекція):

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

Учасники:

1. Автор продукту і можливо колеги автора (аналітик, що склав документацію вимог)

2. Автор будь-якого попереднього продукту для елемента, який варто перевірити.

3. Люди, що виконують роботу, що базуються на перевіряємому елементі.

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

Проблеми перевірки:

1. Великий об’єм документації

2. Велика команда експертів (бажано не більше шести)

3. Географічній роздій інспекторів (доводиться зв’язуватись по відео або пошті)

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

Ролі експертів:

1. Автор. Створює та підтримує продукт, що перевіряється. Тобто аналітик, що розробляв спеку.

2. Координатор – керівник перевірки, планує експертизу сумісно з автором, погоджує особливості і організовує нараду.

3. Читач. Один із перевіряючих виступає в ролі читача. На нараді він перефразовує положення спеки – по одній вимозі за раз.

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

Рішення про завершення експертизи приймається відповідно до одного (будь-якого) з трьох критеріїв:

1. Прийняття з відсутністю або малою необхідністю переробки

2. Прийняття з перевіркою перероблених фрагментів.

3. Необхідність повторної експертизи.