27.03.2012 Лекція: Специфікація вимог до пз Характеристики правильно складеної спеки

Коректність. Спека є коректною, якщо кожна вимога, яка вкладена в ній є вимогою, якій повинно задовольняти ПЗ. (Чи правильно спека визначає потреби користувача даної системи).

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

Повнота (завершеність). Спека є повною, якщо вона включає наступні елементи:

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

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

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

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

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

Двома типами ймовірних конфліктів в спеці є наступні:

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

• Між двома заданими діями може існувати логічний або тимчасовий поті. Наприклад, одна вимога може встановлювати, що «А» повинно завжди слідувати за «Б», в той час як інша може вимагати, щоб події «А» і «Б» відбувалися одночасно.

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

Як правило, всі вимоги, які стосуються ПП, не є важливими в рівній мірі. Деякі вимоги можуть бути неєхидними, в той час, як інші можуть бути бажаними.

Кожна вимога в спеці повинна бути ідентифікована (необхідна або бажана), щоб зробити ці відмінності чіткими і явними. Ідентифікація вимог наступним чином допомагає:

1. Замовникам більш ретельно розглянути вимогу, що часто дозволяє роз’яснити будь-які приховані припущення, які можуть бути укладені в них.

2. Розробникам прийняти правильні проектні рішення, прикласти відповідні зусилля до різних складових програмного вибору.

Ступінь необхідності. Другий спосіб впорядкування вимог полягає в том, що б розрізняти класи вимог як необхідні, умовні і необов’язкові.

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

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

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

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

Неперевіряємі вимоги включають формулювання типу «працює добре», «гарний інтерфейс з користувачем» і «зазвичай має відбуватися». Ці вимоги не можуть бути перевірені.

Прикладом перевіряє мого твердження є наступне: Вихідні дані програми повинні вироблятися в межах 20 секунд протягом 60% часового інтервалу подій і повинні вироблятися в межах 30 секунд протягом 100% часового інтервалу подій.

Якщо не можна винайти метод, щоб визначити відповідає ПЗ певній вимозі, то цю вимогу слід виключити.

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

Якщо правило кодифікованість вимагає, щоб спека:

1. Мала зв’язану і легку у використанні структуру зі змістом, алфавітним покажчиком.

2. Не була надмірною (тобто, одна і та ж вимога не повинна з`являтися в спеці більше ніж в одному місці).

3. Висловлювала кожну вимогу роздільно, не змішуючи її х іншими вимогами.

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

Рекомендуються наступні два типи відслідковуваності:

1. Зворотня відслідковуваність (до попередніх стадій розробки). Залежить від кожної вимоги, яке в явному вигляді посилається на її джерело в більш ранніх документах.

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

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