9 Класифікація вимог до програмного забезпечення: функціональні і нефункціональні вимоги, користувацькі і системні вимоги

Функціональні вимоги визначають «що» повинен робити програмний продукт. Наприклад, швидкість, розмір програми, простота експлуатації, надійність.

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

Системні вимоги — вимоги до програмних інтерфейсів, надійності, обладнання.

10 Розробка вимог: аналіз здійсненності, формування і аналіз вимог

Розробка вимог – це заходи, необхідні для створення і затвердження документа, що містить специфікацію системи. Аналіз здійсненності повинен дати відповіді на такі питання: Чи відповідає програма загальним і бізнес цілям замовника і розробника; Чи можна реалізувати систему існуючими технологіями. Чи можна об'єднати цю програму з іншими. Під час аналізу здійсненності визначають джерела вимог і методи збору вимог. Процес формування і аналізу вимог проходить через ряд етапів: 1. Аналіз предметної області; 2. Збір вимог; 3. Класифікація вимог; 4. Вирішення протиріч; 5. Визначення пріоритетів; 6. Перевірка вимог.

11 Розробка вимог: атестація, керування

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

• Перевірка правильності вимог.

• Перевірка на несуперечливість.

• Перевірка на повноту.

• Перевірка на виконуваність.

Керування вимогами – це процес керування змінами системних вимог. Виконується разом з іншими процесами розробки вимог.

12 Моделі системного оточення. Моделі поведінки

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

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

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

ПОВЕДІНКОВІ Ці моделі використовуються для опису загальної поведінки системи. Тут розглядається два типи поведінкових моделей - модель потоків даних, яка представляє обробку даних у системі, і модель кінцевого автомата, яка показує реакцію системи на події. Ці моделі можна використовувати окремо або спільно, залежно від типу системи, що розробляється.