5. Перевірка вимог

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

Характеристика	Міра
Продуктивність	Кількість транзакцій за секунду Час відгуку
Розмір	Кількість записів у базі даних Потрібний розмір пам'яті
Зручність для користувача	Час, потрібний для навчання Розмір документації
Надійність	Вірогідність помилки транзакції Час між виконаннями Доступність (час, коли програма доступна для користувача) Час перезавантаження програми після помилки Вірогідність втрати даних після помилки
Переносимість	Розмір платформозалежного коду Кількість платформ Вартість перенесення

Малюнок 5.6.1. Перевірка нефункціональних вимог.

6. Документ з вимогами

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

Приклад такого документа:

План Тіло документу Стандарт: ANSI/IEEE std 830-1993 Рекомендований порядок специфікації вимог програмного забезпечення	Резюме (не більше 200 слів) Зміст Статус документу: автори, компанії, дати і т.д. Зміни, зроблені після останньої версії
	1.  Вступ 1.1 Ціль 1.2 Контекст 1.3 Визначення, скорочення, абревіатури 1.4 Посилання 1.5 Короткий огляд 2.  Загальний опис 2.1 Зручність роботи з програмою 2.2 Загальні характеристики 2.3 Характеристики користувача 2.4 Умови роботи 2.5 Припущення та взаємозв'язки 3.  Вимоги 3.1 Функціональні вимоги 3.2 Нефункціональні вимоги Доповнення

Малюнок 5.7.1. Документ з вимогами.

Послідовність дій, застосованих до документа, повинна бути наступною:.

Якщо немає інформації, записати "не додається".

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

Будь-який матеріал, що не ввійшов до секції, повинен бути доданий в "Додаток".

Часто до документа додаються:

• Вимоги апаратного і програмного забезпечення,

• Модель системи (архітектура),

• Словник (термінологія, акроніми, абревіатури),

• Зміст.

Якість документа з вимогами

Найбільш важливі чинники для якісних вимог:

Стиль

• Ясність: однозначне формулювання, ясне для користувача і розробника,

• Структура документа,

• Відповідність: ніяких протиріч у формуванні вимог,

• Змінність: формулювання по ключових моментах.

Гнучкість

• Можливість додавання нових вимог.

Специфікація ролей

• Можливість пов'язати особу з вимогою, описувати дію вимоги.

Помірність

• Паперовий або електронний варіант,

• Контроль версії документа.

Словник

Не може бути незрозумілих термінів для якої-небудь із сторін.

Всі специфічні треміни повинні бути додані в словник.

Всі невизначеності повинно бути уточнено. Приклад:

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

Малюнок 5.7.2. Словник.