Основи розробки вимог. Лекція №5

1.

ЛЕКЦІЯ №5
ОСНОВИ РОЗРОБКИ ВИМОГ

2.

План
■ Поняття вимог:
– Термінологія
– Джерела вимог
– Важливість уваги до вимог
– Типові проблеми під час роботи з вимогами
■ Види вимог:
– Бізнес-вимоги
– Вимоги користувачів
– Функціональні вимоги
– Інші види вимог
■ Основи інженерії вимог:
– Розробка вимог
– Управління вимогами

3.

Поняття "вимог"
ВИМОГИ (Requirements) -це набір описів бажаних від
розробляємої програмної системи функцій, якісних
характеристик системи, а також обмежень, що
накладаються на методи її розробки
■ Більшість людей, як правило, включаючи і
замовників, розуміють термін "вимоги" як
список обов'язкових до виконання інструкцій,
як саме повинна працювати система, що
розробляється.
■ Більшість розробників розуміє термін
"вимоги" як опис потенційних можливостей
системи, частина з яких, ймовірно, буде
реалізована.

4.

Джерела вимог
Зацікавлені особи
Експерти у
предметній галузі
Системи
конкурентів
Відкриті джерела
Досвід розробників
Можливості
технологій
Успадковані
системи

5.

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

6.

Вартість виправлення дефекту
Вартість виправлення помилки на етапі вимог у 30-100
разів менша за виправлення помилки після
впровадження

7.

"Прірва очікувань«
(expectation gap)
Спостереження: розробникам властиво бажання почати
конструювати реалізацію системи якомога швидше
Частота комунікації із замовником прямо впливає
на ширину прірви між потребами та рішенням

8.

Розподіл зусиль щодо роботи з вимогами
протягом проекту
Висновок: неітераційна
технологія (водопадний процес)
застосовна лише в контексті, де
вимоги зрозумілі та стійкі
Якщо спостерігається значна мінливість вимог, ризики
водоспадних процесів значно вищі, ніж ітераційних, і тим більше
гнучкіших, де комунікація відбувається набагато частіше.

9.

Гарячі ознаки проблем із
вимогами у проекті
Глобальні
Не визначено бізнес-цілі
проекту
Проектні кордони розмиті,
розсуваються по ходу проекту
Контакт замовників та
розробників відсутній або
надто рідкісний
Замовник вважає, що вже
все пояснив розробникам
Замовник ніколи не
підтверджував вимоги
Система розроблена та
впроваджена, а бізнес-цілі не
досягнуто
Часткові
Розробники самостійно
приймають рішення щодо змін
вимог
Спілкування із замовником
зводиться до обговорення
інтерфейсу користувача
Замовник часто змінює
підтверджені вимоги
Усі вимоги однаково критичні
для замовника
Втрачено запити на зміни вимог
Запитаною функцією системи
ніхто не користується

10.

Типові проблеми із вимогами
Проблеми з
вимогами
Неповнота
Неточність
Надмірність
Неявні
знання
Проблеми
формулювання
Дуплікація
Недорозуміння
потреб
Проблеми з
комунікацією
Розростання
Невиявлені
ролі
Спотворення
Конфлікт
вимог
Неперевірюваність
вимог

11.

Якості хорошої вимоги
Хороші вимоги повинні мати такі характеристики:
- Однозначність
- Тестованість (ті, що можуть бути перевірені)
- Ясність (лаконічність, краткість, проста, точність)
- Коректність
- Зрозумілість
- Здійсненність (реалістичність, можливість)
- Незалежність
- Атомарність
- Необхідність

12.

Різноманітність видів вимог
Кожен еліпс є різновидом вимог :

13.

3 основні рівні вимог
■ Бізнес-вимоги: відображають НАВІЩО
ініційований конкретний проект, є
прямим результатом процесу бізнесаналізу на стороні замовника/відділу
маркетингу
■ Вимоги користувача: відображають
МОЖЛИВОСТІ користувача у
майбутній програмній системі
■ Функціональні вимоги: відображають
ЩО КОНСТРУЮВАТИ розробникам та
ЩО ТЕСТУВАТИ тестувальникам

14.

Бізнес-вимоги
БІЗНЕС-ВИМОГИ(business requirements) - це високорівневі
проблеми або цілі в діловому контексті, які неявно переслідуються
замовниками при прийнятті рішення про розробку нової або
розвитку існуючої інформаційної системи. Цей вид вимог пояснює
НАВІЩО ініційована розробка, але не вказує ЩО і ЯК має бути
створено.
Бізнес-кейс
Бізнес-вимоги

15.

Бізнес-правила
БІЗНЕС-ПРАВИЛА– множина формальних політик, інструкцій,
стандартів та розпоряджень, що визначають або обмежують різні
аспекти ведення бізнесу, який автоматизує IT-система
Бізнес-правила не використовуються як безпосередні
вимоги до ПЗ, проте суттєво впливають на них та
можуть бути додатковим джерелом вимог

16.

Вимоги користувача
(User Requirements)
ВИМОГИ КОРИСТУВАЧА (user requirements) описують конкретні дії
та завдання, які можуть мати цінність завдяки використанню
системи. Цей набір вимог є описом ЩО саме повинна робити
система з погляду користувача.
User
Requirements
Текст завданної
структури
Прецеденти
використання
(use cases)
Історії
користувача
(user stories)

17.

Функціональні вимоги
ФУНКЦІОНАЛЬНІ ВИМОГИ ДО ПЗ(software functional requirements) - це
детальні специфікації поведінки, що пояснюють розробникам, що
саме має бути сконструйовано, щоб замовники могли отримати
реалізацію користувацьких вимог, забезпечивши очікувані від
проекту потреби.
Основа для
проектування та
розробки
Основа для складання
плану тестування
Фіксується у документі
Software Requirements
Specification

18.

Інші види вимог
НЕФУНКЦІОНАЛЬНІ ВИМОГИ ДО ПЗ(software nonfunctional
requirements) –опис очікувань від характеристик роботи системи,
що розробляється, які прямо не стосуються її функцій, але
значною мірою впливають на задоволення кінцевих користувачів.
ВИМОГИ ДО ЗОВНІШНІХ ІНТЕРФЕЙСІВ- очікування щодо
надання спеціальних точок входу для зовнішнього програмного
доступу з метою управління або спостереження за роботою
системи, що необхідні для поєднання з іншими програмними
системами .
ОБМЕЖЕННЯ НА РОЗРОБКУ–опис технічних чи
організаційних правил, що звужують ступінь свободи
колективу розробників під час реалізації системи

19.

Інженерія вимог
ІНЖЕНЕРІЯ ВИМОГ(requirements engineering) – це
системний підхід до отримання, організації та
документування вимог до системи, та процес
встановлення та підтримки домовленостей між
замовниками та розробниками про вимоги, що
постійно змінюються.

20.

Виявлення вимог
(Requirements Elicitation)
ВИЯВЕННЯ ВИМОГ охоплює встановлення з багатьох
джерел необхідних початкових відомостей для
формулювання набору вимог, включаючи:
■ ідентифікацію різних груп користувачів та інших
зацікавлених осіб;
■ отримання розуміння цілей та завдань користувачів, і
мотивації, що пов'язана з цими цілями та
завданнями та обумовлена конкретним діловим
контекстом;
■ вивчення бізнес-середовища, в якому буде
застосовуватись програмний продукт;
■ роботу з конкретними людьми, що представляють групи
користувачів, спрямовану на виявлення функціональних
потреб та якісних очікувань;
■ попередню оцінку здійсненності проекту

21.

Аналіз вимог
(Requirements Analysis)
АНАЛІЗ ВИМОГ–процес досягнення більш
ширшого та точного рівня розуміння кожної
конкретної вимоги та визначення зручного
способу її подання, що включає:
■ структуризацію одержаної інформації
■ деталізацію високорівневих вимог;
■ синтез неявних функціональних вимог;
■ отримання розуміння важливості атрибутів якості;
■ групування вимог до ієрархії;
■ узгодження та уточнення вимог;
■ виявлення прогалин та надлишкових вимог;
■ встановлення пріоритетів;
■ аналіз ризиків та оцінка вартості реалізації.

22.

Валідація вимог
ВАЛІДАЦІЯ ВИМОГ –процес
підтвердження досягнення коректного
набору вимог, який дозволить
розробникам побудувати рішення, яке б
задовольняло потреби бізнесу, що
включає:
■ Перегляд документованих вимог для
коригування будь-яких проблем до
моменту фіксації
■ Розробка приймальних критеріїв та
тестів, що підтверджують, що продукт,
побудований на вимогах, задовольнить
бажанням користувачів та досягне
бізнес-цілей

23.

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

24.

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

25.

Управління вимогами
(Requirements Management)
ЗАТВЕРДЖЕНІ ВИМОГИ(baselined requirements) – версія набору вимог
всіх рівнів, яка приймається за основу плану реалізації.
УПРАВЛІННЯ ВИМОГАМИ–
процес встановлення набору
затверджених вимог для
конкретного запланованого
випуску програмного
забезпечення, а також
формального протоколу для
внесення узгоджених наступних
необхідних змін

26.

The End
Дякую за увагу!