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. Словник.

7. Чинники успіху

Ключові чинники успіху етапу формулювання вимог:

• Надання лієнту зразків для усунення неясності,

• повна ідентифікація вимог, виявлення специфічних і виняткових вимог. ,

• завершеність і перевірка змісту,

• формулювання нефункціональних вимог в певній формі.

8. Короткий звіт

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

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

VI. Розробка моделі

1. Потреба в розробці моделі

Модель - це представлення концепції якоїсь реальності. Розум людини завжди займався розробкою моделей, будь то математичні моделі, фізичні, моделі машин, будинків і т.д.

Яка мета розробки моделі?

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

Розробники інформаційних систем використовують моделі.

Зазвичай створюють наступні моделі:

• модель вимог - описується, наприклад, випадками використання,

• аналітична модель - статика і динаміка системи описуються мовою UML; деталями реалізації нехтують,

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

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