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

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

Основні поняття, рівні та

типи вимог
Визначення вимоги до ПЗ
 Поняття вимог до ПЗ
Вимоги * - це:

1. умови або можливості, необхідні користувачеві для вирішення проблем

або досягнення цілей
2. умови або можливості, якими повинна задовольняти система або її
компоненти, щоб виконати контракт або бути у відповідності зі
стандартам, специфікаціям або іншим формальним документам
3. документоване подання умов або можливостей з пунктів 1 і 2
 Поняття вимог до ПЗ
У нашому випадку - вимоги, це вихідні дані, на підставі яких проектуються і
створюються програмні системи
Вони визначають ЩО замовник хоче від системи

Вимоги вказують на те, ЩО повинна робити система, однак не повинні вказувати ЯК

Поняття вимог до ПЗ
 Важливість виявлення вимог до ПЗ
Ф. Брукс —американський
вчений з теорії
обчислювальних систем, автор
книги “Міфічний людино-
місяць”, керівник розробки
OS/360 з IBM, який отримав
премію Тьюрингу у 1999 році.
За Ф.Бруксом:
Найсуворіше і єдине правило побудови систем програмного
забезпечення (ПЗ) - вирішити точно, що ж будувати
Ніяка інша частина концептуальної роботи не є такою важкою,
як з'ясування деталей технічних вимог, в тому числі взаємодії з
людьми, з механізмами та з іншими системами
Ніяка інша частина роботи так не псує результат, якщо вона
виконана погано. Помилки ніякого іншого етапу роботи не
виправляються так важко
 Важливість виявлення вимог до ПЗ

За результатами звіту групи Стендіша (1994 рік) найбільш поширеними факторами,

що створюють проблеми при розробці ПЗ є:

• Неповна вихідна інформація від клієнта - 13% всіх проектів

• Неповні вимоги і специфікації - 12% всіх проектів
• Постійна зміна вимог і специфікацій під час проекту - 12% всіх проектів
 Важливість виявлення вимог до ПЗ
• Ціна помилок і нечітких, неоднозначних формулювань у вимогах призводить до
того, що час і кошти витрачаються на непотрібну замовнику програму

• Статистика показує, що відсоток помилок в постановці завдань перевищує

відсоток помилок в реалізації

• На помилки, внесені на етапі збору вимог, доводиться від 40 до 50% всіх дефектів,
виявлених в програмному продукті (Davis, 2005)
Джерела вимог
 Джерела вимог
Зацікавлені особи та
користувачі

Джерала вимог Документи

Інші системи
Джерела вимог: Документи
Стратегія підприємства

Стандарти ( у тому числі

галузеві)

Документи Законодавство

Документи з вимогами від

Замовника

Бізнес-процеси Замовника

Керівництво користувача
Джерела вимог: Інші системи
Системи з аналогічною
функціональністю

Попередні версії системи

Інші системи

Системи конкурентів

Пов’язані системи та плани

з іх розвитику
 Документи: Стратегія підприємства
Стратегія підприємства - «це визначення основних довгострокових цілей і завдань
підприємства та затвердження напрямку дій та розподілу ресурсів, необхідних для
досягнення цих цілей»
У стратегії ми можемо знайти:
• існуючі проблеми,
• бізнес-цілі організації,
• основних конкурентів,
• інформацію про поточних і потенційних користувачів
• інше
 Джерела вимог:Стратегія
підприємства
Стратегія містить:
1. Оцінка існуючого стану підприємства:
1.1 Опис підприємства;
1.2 Опис галузі та перспектив її розвитку;
1.3 Основні проблеми, що стоять перед підприємством;
1.4 SWOT-аналіз (Сильний та Слабкі сторони, Можливості, Загрози)
2. Загальна стратегія розвитку підприємства:
2.1 Місія;
2.2 Стратегічні цілі:
2.3 Ринкові цілі;
2.4 Виробничі мети;
2.5 Фінансово-економічні цілі;
2.6 Соціальні цілі .
3. Шляхи досягнення поставлених цілей.
3.1 Зміни в сфері управління;
3.2 Зміни в сфері виробництва;
3.3 Зміни в сфері збуту.
 Джерела вимог: Керівництво
користувача/Оператора

Керівництво користувача / оператора- документ, призначення якого - надати допомогу

в використанні деякої системи

Типове керівництво користувача містить:

• Глави, що описують, як використовувати найбільш важливі функції системи

• Глава, що описує можливі проблеми та шляхи їх вирішення
• Глосарій
 Джерела вимог: Галузеві стандарти
Стандарт (від англ. Standard - норма, зразок) в широкому сенсі слова - зразок, еталон,
модель
Наприклад, при розрахунку банківськими
картками необхідне дотримання стандарту
PCI DSS
Для забезпечення безпечного з'єднання між
системами використовується протокол TSL,
описаний в стандарті RFC 6176
 Джерела вимог: Законодавство

Законодавство України можна знайти на http://zakon.rada.gov.ua

Розглянемо деякі закони, які потрібно вивчити, якщо ви замовляєте сайт або
ведете діяльність у сфері електронної комерції

Підприємцю-початківцю здається все просто: є сайт, є товар, є покупець, є

способи оплати. Вперед, отримувати прибуток
 Джерела вимог: Законодавство
1. Покупець web-магазину має бути проінформований:

Згідно зі статтею 7 Закону України «Про електронну комерцію» підприємець у сфері

інтернет торгівлі повинен розміщувати наступну інформацію на сайті:

● повне найменування юридичної особи або ПІБ фізичної особи-підприємця (ФОП)

● відомості про місцезнаходження юридичної особи або місце реєстрації та місце
фактичного проживання (для ФОП)
● адреса електронної пошти та / або адреса інтернет-магазину
● ідентифікаційний номер платника податків (ІПН) для юридичних осіб або
реєстраційного номера облікової картки платника податків для ФОП. Паспортні дані
для ФОП, якщо в зв'язку з релігійними переконаннями був офіційну відмову від
отримання реєстраційного номера облікової картки платника податків
 Джерела вимог: Законодавство
● відомості про ліцензії - серія, номер, термін дії та дата видачі, якщо діяльність
підлягає ліцензуванню
● інформацію про включення в розрахунок вартості товару, роботи або послуги
податків
● інформацію про вартість доставки

П.7 ст.23 закону «Про захист прав споживачів» від 12.05.91 №1023-XII передбачає
відповідальність за відсутність необхідної, доступної, достовірної та своєчасної
інформації про продукцію або продавця (у випадках, визначених законом «Про
електронну комерцію»)
 Джерела вимог: Законодавство
2. Продавець також зобов'язаний:

● отримати попередню згоду Покупця для направлення йому комерційних електронних

повідомлень (реклама інтернет-магазину / товару), а в протилежному випадку - надати
Покупцю реальну можливість відмовитися від подальшого отримання таких повідомлень
● забезпечити дотримання вимог Закону щодо змісту комерційних електронних
повідомлень, що направляються потенційному Покупцю: доступ до інформації про
Продавця, відомості про вартість товару, доставку, податки та інше
● забезпечити належний захист наданим Покупцем відомостей про його платіжні
інструменти для оплати вартості придбаного товару від несанкціонованого доступу з боку
третіх осіб. Тобто мається на увазі, захист відповідну законам «Про захист інформації в
інформаційно-телекомунікаційних системах" та "Про платіжні системи та переказ коштів
в Україні"
 Джерела вимог: Законодавство
● Безпосередньо або через оператора платіжної системи, який отримав оплату за товар,
надати Покупцеві електронний документ (квитанцію, товарний чи касовий чек, інший
документ), який підтверджує факт отримання коштів, із зазначенням дати здійснення
розрахунку.
● Надати Покупцеві в момент укладення електронного договору або в момент доставки
товару підтвердження укладення електронного договору в формі електронного документа
(квитанції, товарного або касового чека або іншого документа), яке повинно відповідати
вимогам Закону.
● Забезпечити відповідність товару, придбаного Покупцем, його кількісним і якісним
характеристикам, які наведені на сайті або в комерційному електронному повідомленні.
● Забезпечити архівне зберігання електронних документів, пов'язаних з укладенням
електронного договору купівлі-продажу, протягом не менше терміну позовної давності, якщо
законом або правилами користування сайтом (здійснення покупок) визначено термін їх
зберігання.
Рівні вимог
Високорівневі

Бізнес
вимоги

Вимоги користувачів

Функціональні вимоги

Деталізовані
 Відповідність між функціональним
вимогами, вимогами користувачів та
бізнес вимогами
Вимоги користувачів та функціональні вимоги до ПЗ повинні відповідати бізнес-
вимогами

Вимоги,що не сприяють досягненню бізнес-цілей проекту,не повинні бути

реалізованими
Види вимог
Типи вимог за класифікацією
К.Вігерса та їх приклади

Cамостійне вивчення:
● Системні вимоги
● Зовнішні
інтерфейси
● Обмеження
 Бізнес вимоги
Бізнес-вимоги (Business Requirements) - визначають високорівневі бізнес-цілі
організації або замовників системи

Які цілі за допомогою системи ми хочемо досягти?

Чому потрібна розробка система або зміна у існуючий?

Джерело вимог: ті, хто фінансує проект

• покупці системи (Замовники)

• менеджери реальних користувачів
• відділ маркетингу
 Бізнес вимоги
Записані в:
в документі про Концепцію та Межі проекту (Vision and Scope document)

Іноді можуть бути записані в:

• статут проекту (project charter),
• вимогах ринку (market requirements document)
 Бізнес вимоги
Концепція продукту (product vision) стисло описує кінцевий продукт, який досягне
заданих бізнес-цілей
Межі проекту (project scope) описують:
• межу між тим, що входить в проект і тим, що залишається зовні
• на яку частину кінцевої концепції продукту буде направлений поточний проект
або ітерація
 Приклади бізнес-вимог
Фінансові цілі:

БТ1: Збільшити частку ринку в країні Україна на 5%

за 12 місяців

БТ2: Отримати 25% прибутку або доходу з інвестицій протягом 6 місяців

БТ3: Досягти позитивного балансу по цьому продукту протягом 9 місяців

БТ4: Заощадити $ 45000 на рік, які зараз витрачаються на обслуговування програмної

системи

БТ5: Зменшити витрати на підтримку на 25%

за 24 місяців
 Приклади бізнес-вимог
Нефінансові цілі:
БТ6: Досягти показника задоволення покупців, рівного принаймні 0.65, протягом 6
місяців з часу випуску продукту

БТ-7: Збільшити продуктивність обробки транзакцій на 15% і знизити рівень

помилок даних до величини не більше 2%

БТ8: Отримати 30 позитивних відгуків в галузевих журналів до певної дати

БТ9: Домогтися визнання продукту найкращим

по надійності в опублікованих оглядах продуктів до певної дати
 Вимоги користувачів
Вимоги користувачів (Users 'requirements) - визначають:
• цілі і завдання, які користувачам потрібно вирішити за допомогою програмної системи
• атрибути / характеристики, які важливі для задоволення користувачів

Які завдання можна буде вирішити за допомогою системи?

Що може користувач робити за допомогою системи?
Джерело вимог: Реальні користувачі
Сформульовані у вигляді:

• Варіантів використання (use case)

• Історій користувача (user story)
• Таблиці подія-відгук
Вимоги користувачів - Приклад запису
у вигляді Варіанту Використання
Вимоги користувачів - Приклад запису
у вигляді Варіанту Використання
Вимоги користувачів - Приклад запису
у вигляді Варіанту Використання
 Функціональні вимоги
Функціональні вимоги (functional requirements) - визначають функціональність, яку
розробники повинні створити, щоб користувачі змогли виконати свої завдання

Поведінка продукту в тих чи інших умовах

Записані в: специфікації вимог до ПЗ (software requirements specification, SRS)

Сформульовані у вигляді:
Cистема {Назва} повинна ...
Система {Назва} не повинна ...

The MCRS must ...

The MCRS must not ...
 Функціональні вимоги
Банкомат повинен відображати початковий екран, якщо в нього не вставлена ​карта

Система повинна почати авторизацію, після того, як користувач вставив карту в

пристрій, що зчитує

Банківська система повинна перевіряти дійсність вставлену в банкомат Картки

Банківська система повинна перевіряти

достовірність PIN-коду, введеного Користувачем
 Функціональні вимоги
Банкомат повинен відображати початковий екран, якщо в нього не вставлена ​карта

Банкомат не повинен приймати карту, якщо в ньому закінчилися гроші

Система повинна почати авторизацію, після того, як користувач вставив карту в

пристрій, що зчитує

Банківська система повинна перевіряти дійсність вставлену в банкомат Картки

Банківська система повинна перевіряти достовірність PIN-коду, введеного

Користувачем
 Різниця між функціональнити та
нефункціональними вимогами

Функціональні вимоги

що повинна робити система?

Атрибути якості (нефункціональні вимоги)

при дотриманні яких умов?

 Різниця між функціональнити та
нефункціональними вимогами
Яка з перерахованих вимог є функціональною, а яке нефункціональною?

• Система ATM повинна перевіряти дійсність вставленої в банкомат Картки.

• Система ATM повинна перевіряти дійсність картки ATM протягом трьох секунд
 Різниця між функціональними та
нефункціональними вимогами
Система ATM повинна перевіряти дійсність вставленої в банкомат Картки

Що система повинна робити?

Це функціональна вимога!
 Різниця між функціональнити та
нефункціональними вимогами
Система ATM повинна перевіряти дійсність картки ATM протягом трьох
секунд
При дотриманні яких умов?

Це атрибут якості?
 Бізнес-правила (Business Rules)
Бізнес-правила (Business Rules) - положення, які:

• або інформують вас, чи можете ви зробити щось чи ні,

• або дають вам критерії та умови для прийняття такого рішення

Базуються на корпоративній політиці, регламентах, галузевих стандартах,

законодавчих актах і т.д.

Не є вимогами до програмної системи, проте накладають обмеження на неї

 Приклади Бізнес-правил
БП1: Водій повинен мати дійсні права.

БП2: Водійське посвідчення є дійсними, якщо виконується наступне:

• Права належать даному водієві

• Дата закінчення терміну дії більше ніж дата перевірки прав

• Категорія, відкрита водієві в рамках даних прав, відповідають типу

транспортного засобу, яким керує водій
 Види бізнес правил

• Факти (facts)

• Обмеження (constraints)

• Активатори операції

• Висновки (inference)

• Обчислення
 Факти
Факти (facts) - вірні твердження про існуючий бізнес.

Приклади:

Оплата здійснюється за доставку кожного замовлення

З вартості доставки податок не береться

 Обмеження
Обмеження (constraints) - обмежують перелік операцій, які може виконувати система
або її користувачі

Сформульовані у вигляді:

повинен
не повинен
не може виконувати певні дії
тільки певні особи можуть
тільки певні ролі можуть
 Приклади обмежень
З політик організацій:

• Договір позики особа молодше 18 років повинна підписувати або з одним з його
батьків або з законним опікуном, що є поручителем

• Постійний відвідувач бібліотеки може відкласти для себе до 10 книг

З державних нормативів:

• Екіпажі комерційних авіарейсів повинні кожні 24 години відпочивати не менше 8

годин
 Активатори
Активатори операції (Тригери) - правило, яке за відповідних умов призводить до
виконання певних дій

«Якщо <деяка умова вірна або трапилась певна подія>, то <щось станеться>»

Приклади

• Якщо клієнт замовив книгу автора, що написав більше однієї книги, то клієнту,
перш ніж прийняти замовлення, слід запропонувати інші книги цього автора,

• В останній день кварталу бухгалтер має зробити податковий звіт

 Висновки
Висновок (inference) - це правило, яке встановлює нові реалії у разу достовірності
певних умов

«Якщо <деяка умова вірна або настала певна подія>, то <факт або
припущення>»

Приклади
• Якщо платіж не надійшов протягом 30 календарних днів з моменту відправки
рахунку, рахунок вважається простроченим

• Якщо постачальник не може поставити замовлений товар протягом п'яти днів з

моменту отримання замовлення, замовлення вважається невиконаним
 Обчислення
Обчислення (computations), що виконуються
з використанням математичних формул і алгоритмів

Ціна одиниці товару знижується на 10% при замовленні від 6 до 10 одиниць, на 20% -
при замовленні від 11 до 20 одиниць і на 30% - при замовленні понад 20 одиниць
 5 основних правил для
визначення Бізнес-Правил
Правило №1 Бізнес Правило має нести практичну користь
Це означає, чи буде людина, що читає дане правило, знати, що можна робити
і чого робити не можна
Одягни каску перед входом на будівництво!

Правило №2 Бізнес Правило має давати інформацію про бізнес, а не

про систему,що автоматизує бізнес або платформу, де буде розгорнута
система
Суть цього правила полягає в питанні: якщо ви відкинули в сторону будь-яку
систему, чи буде дане правило
як і раніше грати якусь роль в управлінні бізнесу?
 5 правил для
визначення Бізнес-Правил
Правило №3 Бізнес-правило має бути сформульовано на мові бізнесу, а не на мові
системи або на мові платформи
Це означає, представники бізнесу повинні зрозуміти дане правило без проходження
додаткового IT-тренінгу
Правило №4 Бізнес-правило має бути під юрисдикцією бізнесу
Це означає, що бізнес може:
 Прийняти Бізнес-Правило
 Переглянути (змінити) Бізнес-Правило
 Скасувати Бізнес-Правило
Правило №5 (додаткове) Бізнес Правило повинне обмежувати ступінь свободи
 Різниця між бізнес-правилами та
вимогами

Бізнес-правило:
Для здійснення покупки покупець повинен надати поштову адресу та телефон

Вимоги:
1. Система повинна надати покупцеві можливість вказати свою поштову адресу і
телефон
2. Система повинна надати можливість перевірити коректність телефону і його
приналежність покупцеві шляхом відправки коду підтвердження на вказаний номер
телефону
Класифікація інформації від
Замовника
Класифікація інформації від
Замовника/Користувача
 Ключові фрази
Бізнес вимоги

• « Збільшити щось з X% до Y% протягом

наступних N місяців »

• «Заощадити Y доларів в рік за рахунок того-то, Висловлює той, хто платить

що зараз витрачається неефективно»

• Бізнес правила

• «Повинна відповідати ...»

• «Якщо <умова вірна>, тоді має відбутися то-то»
• «Повинно обчислюватися відповідно до …»
 Ключові фрази
Вимоги користувача Функціональні вимоги
Замовник описує очікувану поведінку
«Мені потрібно зробити те-то і те-то за системи при певних умовах і дії, які система
допомогою системи» має дозволяти користувачам виконувати:

"У користувача повинна бути можливість

сортувати список проектів в прямому і
зворотному алфавітному порядку
 Ключові фрази
Функціональні вимоги
Замовник описує очікувану поведінку
системи при певних умовах і дії, які система
дозволить виконувати користувачам:
"У користувача повинна бути можливість
сортувати список проектів в прямому і
зворотному алфавітному порядку
Функціональні вимоги
Бізнес-аналітик повинен перетворити
ці висловлювання в більш точні
специфікаці
Атрибути якості
Замовник описує наскільки добре система
має виконувати щось.
У промові: швидка, легка, інтуїтивно
зрозуміла, зручна для користувача, стійка
до збоїв, надійна і ефективна
Атрибути якості
Бізнес-аналітик повинен попрацювати з
користувачами і перетворити нечіткі і
суб'єктивні терміни в чіткі атрибути
якості, які можна перевірити
 Ключові фрази
Вимоги до інтерфейсів Обмеження
Замовник описує те, що обмежує
Замовник описують зв'язок вашої системи
розробника при виборі варіанта
з рештою світу:
реалізації
• «Повинна розпізнавати сигнали від ...»,
• «Повинна бути написана на певній
• «Повинна відправляти повідомлення
мові програмування»,
на адресу ...»,
• «Не може перевищувати певного
• «Повинна бути в змозі читати (або
значення»
записувати) файли в форматі»,
• «Повинна використовувати певний
• «Елементи користувацького інтерфейсу
елемент управління інтерфейсу
повинні відповідати стандарту такому-
користувача»
то
 Ключові фрази

Вимоги до даних

Замовник описують формат, тип даних, допустимі значення або значення за

замовчуванням для елемента даних або звіту.

“Замовлення складається з ідентифікаційної інформації клієнта, адреси та додаткової

інформації щодо доставки та одного або більше товарів. У кожного з товарів є
номер, число одиниць, ціна за одиницю і загальна сума замовлення.”
 Ключові фрази
Ідеї рішення
1. Замовник:
«Потім в списку, що випадає я вибираю штат, куди я хочу відправити посилку».

2. Постачальник:
Хмм ... "в списку,що випадає " замовник описує конкретний елемент управління
інтерфейсу користувача. Швидше за все це ідея рішення.?
Треба запитати, чому саме в списку
3. Постачальник «Чому саме у списку, що випадає?
 Ключові фрази
Ідеї рішення
4. Замовник: «Мені здається, що так
буде зручно»
4а Замовник: «Я запропонував, список,
тому що ми застосовуємо цей елемент в
інших областях, і я хочу одинакового
вигляду
Крім того, так користувач не зможе
ввести неперевірені дані
5а. Постачальник: Для такого обмеження
поважна причина
4. Функціональна вимога:
«Система моє доволяти користувачу
вибрати штат, куди він хоче відправити
посилку”
4а. Функціональна вимога
«Система моє доволяти користувачу
вибрати штат, куди він хоче відправити
посилку”
Обмеження:
Як елемент управління використовувати
список, що випадає для забезпечення
однаковості і запобігання вводу некоректних
даних
Дякую за увагу!