КИЇВСЬКИЙ УНІВЕРСИТЕТ

ІМЕНІ БОРИСА ГРІНЧЕНКА

Життєвий цикл вимог до ПЗ

Життєвий цикл вимог
Основні етапи життєвого циклу вимог
Основні етапи життєвого циклу вимог
 Основні етапи життєвого циклу вимог
• Elicit (Збір та виявлення вимог)
• Analyse (Аналіз вимог)
• Refine (Перегляд вимог)
• Formalize (Специфікація вимог, документування вимог)
• Verify (Перевірка якості вимог)
• Prioritize (Визначення пріоритетів)
• Validate (Перевірка на відповідність бізнес цілям)
• Approve (Офіційне затвердження вимог)
• Сhange Management (Управління змінами вимог)
 Збір та виявлення вимог (Elicit )
До основних дій відносять:

• Розуміння бізнес-цілей для досягнення яких створюється / змінюється система

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

Включає: всі дії, пов'язані з виявленням вимог, такі як підготовка та проведення

інтерв'ю, нарад, аналіз документів, створення прототипів і інші
 Аналіз вимог (Analyse)
До основних дій відносять:
• аналіз інформації, отриманої від користувачів. Наприклад, відокремлення задач, які
за допомогою створюваної системи користувачі бажають виконати, від
функціональних і нефункціональних вимог, бізнес-правил, ідей рішень та іншої
інформації
• декомпозиція високорівневих вимог до потрібного рівня деталізації;
• виведення функціональних вимог з інформації, що міститься у користувацьких
вимогах
• узгодження пріоритетів реалізації для кожної з вимог;
• виявлення прогалин у вимогах або зайвих вимог, які не відповідають заданим
рамкам проекту
Включає: отримання точного розуміння всіх вимог і подання наборів вимог в різному
вигляді
 Специфікація вимог (Formalize)

Специфікація вимог передбачає перетворення зібраних потреб та завдань користувачів

в письмові вимоги та діаграми, придатні для розуміння, аналізу та використання
цільовою аудиторією
 Перевірка якості вимог (Verify)
Мета даної перевірки, переконатися, що вимоги:
• добре написані (відповідають критеріям якості)
• легко зрозумілі цільовою аудиторією

Критерії якості вимог:

• Коректність
• Однозначність
• Повнота
• Несуперечливість
• Впорядкованість за важливістю і стабільностю
• Можливість перевірки
• Можливість модифікації
• Можливість відстежити (протрасувати)
 Перевірка якості вимог (Verify)
При перевірці якості вимог також перевірять, що діаграми:

• Відповідають стандартам нотацій

• Ефективно відображають реальність

Реальність

Модель
 Перевірка якості вимог (Verify)
Нотація (від лат. notatio - записування, позначення ) - система умовних позначень,
прийнята в будь-якій галузі знань або діяльності

Приклади стандартів нотацій:

BPMN моделювання бізнес-процесів. https://www.omg.org/spec/BPMN/2.0.2

2.0P /PDF

UML 2.5. специфікація, візуалізація, https://www.omg.org/spec/UML/2.5/P

конструювання та DF
документування артефактів
(artifacts) програмних систем, а також
для моделювання бізнес-процесів
 Prioritise (Визначення пріорітетів)

Пріоритизація - це ранжування вимог для визначення їх відносної значущості для зацікавлених

осіб
Ранжувати можна за:

• Вигодою / Користю (Benefit)

• Штрафу у разі нереалізації (Penalty)
• Вартості (сost)
• Ризиком (Risk)
• Взаємозалежностю з іншими вимогами (Dependencies)
• Чутливостю до часу (Time Sensitivity)
• Стабільностю (Stability)
• Відповідністю нормативним нормам (Regulatory or Policy
Compliance)
 Перевірка на відповідність бізнес
цілям (Validate)
Кожна вимога:

• Сприяє досягненню бізнес-цілі проекту

• Знаходиться в рамках проекту
• Задовольняє потреби зацікавленої особи

Сукупність усіх вимог:

• Реалізація сукупності всіх вимог дозволяє досягти бажаного майбутнього стану

 Затвердження вимог (Approve)

Формальна інспекція або Попарний перегляд

Письмова згода

Реалізувати Зацікавлені особи

Доопрацювати
 Затвердження вимог (Approve)

Основа співпраці клієнтів і розробників – це досягнення угоди щодо вимог до

продукту або його частини, яку планується побудувати

Сторони, які беруть участь у виробництві угоди:

• клієнти, які повинні підтвердити, що вимоги задовольняють їхні потреби;

• розробники, які підтверджують, що вони розуміють вимоги і в можуть
їх реалізувати
• тестувальники, які підтверджують, що кожну з вимог можна перевірити;
• керівництво клієнту, що підтверджує, що вимоги відповідають їх бізнес-цілям
 Затвердження вимог (Approve)
Багато організацій просять клієнта поставити свій підпис на документах з вимогами: це означає,
що клієнт їх підтверджує.

Фактично підпис відповідає наступному:

«Підтверджую, що дійсний набір вимог щонайкраще представляє наше розуміння вимог до

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

Базова угода по вимоги (Baseline) – це зафіксований на певний момент набір вимог, якість яких
та відповідність цілям проекту були перевірені, а самі вимоги узгоджені. Цей набір є основою
для подальшої розробки
 Управління змінами
(Change Management)
Коли виникають нові вимоги або змінюються існуючі, зацікавлена ​особа подає запит на
зміну (Сhange Request) використовуючи заздалегідь визначену форму

Рада по змінам оцінює чи можна запит на зміну реалізувати

• вплив запиту на зміну на інші вимоги та компоненти системи

• вартість реалізації та скільки часу на це потрібно
• вигода/ користь від реалізації зміни

І приймає рішення буде реалізован запит на зміну чи ні

Якщо прийнято рішення про реалізацію зміни, то проводиться перегляд (зміна) вимог
(Refine), діаграм і інших проектних документів
З’являється нова базова лінія (Baseline) вимог
Управління змінами
(Change Management)
 Управління вимогами
(Requirement Management)
Управління вимогами
Керування Відстеження Відстеження зв’язків
Керування змінами між вимогами
версіями стану вимог
• Схеми • Визначення • Визначення
• Пропозиція змін
найменування можливих зв’язку вимоги з
• Аналіз впливу зміни
вимог станів вимог іншими
• Прийняття рішення
• Відстеження • Фіксування вимогами
• Оновлення окремих
версій окремих стану кожної • Визначення
вимог
вимог вимоги зв’язку вимоги з
• Оновлення наборів
• Відстеження • Відстеження іншими
вимог
версій наборів стану розподілу елементами
• Оновлення планів
вимог всіх вимог системи
 Література
1. S.Rance, “How to Define, Measure, and Report IT Service Availability”
https://itsm.tools/2017/06/22/how-to-define-measure-and-report-service-availability/

2. “Software Reliability Engineering” https://www.slideshare.net/markturner1999/software-

reliability-engineering-29690275
Дякую за увагу!