- •1. Методи визначення вимог в програмній інженерії
- •1.1 Формування вимог до програмного виробу
- •1.2 Аналіз вимог замовника до пв
- •1 Інтерв'ю
- •Завершення
- •Що треба пам'ятати при опитуванні.
- •2 Анкетування
- •3 Спостереження
- •5 Спільні семінари
- •6 Прототипування
- •4 Самостійний опис вимог
- •7 Верифікація і формалізація вимог
- •8 Актори і варіанти використання
- •1.3 Класифікація rup
1.2 Аналіз вимог замовника до пв
У своїй основі вимоги - це те, що формулює замовник. Мета, яку він переслідує – отримати хороший кінцевий продукт: функціональний і зручний у використанні.
При виявленні потреб користувачів аналізуються моделі діяльності користувачів і організацій, в яких вони працюють, для виявлення проблемних місць. Також використовуються такі прийоми, як анкетування, демонстрація можливих сеансів роботи майбутньої системи, інтерактивні опитування, де користувачам надається можливість самим запропонувати варіанти зовнішнього вигляду системи і її роботи або поміняти запропоновані кимось іншим, демонстрація прототипу системи та ін.
Після виділення основних потреб треба вирішити питання про розмежування області відповідальності майбутньої системи, тобто визначити, які з потреб потрібно намагатися задовольнити в її рамках, а які - ні.
При цьому усі зацікавлені особи діляться на користувачів, які безпосередньо використовуватимуть створювану систему для вирішення своїх завдань, і вторинних зацікавлених осіб, які не вирішують своїх завдань з її допомогою, але чиї інтереси так чи інакше зачіпаються нею. Потреби користувачів треба задовольнити в першу чергу і на це треба виділити більше зусиль, а інтереси вторинних зацікавлених осіб мають бути тільки адекватно враховані в підсумковій системі.
На основі виділених потреб користувачів, віднесених до області відповідальності системи, формулюються можливі функції майбутньої системи, які є послугами, що надаються системою і задовольняють потреби однієї або декількох груп користувачів (чи інших зацікавлених осіб). Ідеї для визначення таких функцій можна брати з досвіду розробників (найбільш часто використовуване джерело) або з результатів мозкових штурмів і інших форм вироблення ідей.
Формулювання функцій має бути досить коротким, ясним для користувачів, без зайвих деталей. Наприклад:
Усі дані про угоди і клієнтів зберігатимуться в базі даних.
Статус виконання замовлення клієнт зможе побачити через інтернет.
Система підтримуватиме до 10000 одночасно працюючих користувачів.
Розклад проведення ремонтних робіт будуватиметься автоматично.
Маючи набір функцій, який досить добре підтримує рішення найбільш суттєвих завдань, з якими доведеться працювати системі, можна складати вимоги до неї. Співвідношення між проблемами, потребами, функціями і вимогами показане на рис. 8.6.
Проблеми
Необхідності
Функції
Вимоги до ПВ
Чіткість,
Конкретність,
Повнота
Рис. 1.1 Співвідношення між проблемами, потребами, функціями і вимогами
При цьому часто треба враховувати, що ПВ є частиною програмно-апаратної системи, вимоги до якої потрібно перетворити у вимоги до програмної і апаратної частинам.
Кожна вимога розкриває деталі поведінки системи при виконанні нею деяких функції в деяких обставинах.
Ще до переходу від функцій до вимог корисно розставити пріоритети і оцінити трудомісткість їх реалізації і ризики. Це дозволить відмовитися від реалізації найменш важливих і найбільш трудомістких, не відповідних бюджету проекту функцій ще до їх детального опрацювання, а також виявити можливі проблемні місця проекту - найбільш трудомісткі і неясні з функцій, що увійшли до нього.
Стратегії виявлення вимог
