BUSINESS REQUIREMENTS SPECIFICATION – [Назва проекту]

Лабораторна робота №2
Розробка специфікації бізнес-вимог до ПЗ
Мета роботи: Аналіз інформації щодо бачення програмного рішення
стейкхолдерами та розробка специфікації бізнес-вимог до ПЗ

Задачі:
1 Вивчення методів аналізу інформації щодо бізнес-вимог до програмної
системи.
2 Аналіз інформації щодо бачення програмного рішення стейкхолдерами
3. Розробка специфікації бізнес-вимог до ПЗ (яке розробляється в межах
виконання дипломної роботи) згідно шаблону.

2.1 ТЕОРЕТИЧНА ЧАСТИНА

2.1.1 Формулювання бізнес-вимог

Термін бізнес-вимоги (business requirements) відноситься до інформації,
яка в сукупності описує потребу, яка ініціює один або більше проектів,
покликаних надати рішення і отримати необхідний кінцевий бізнес-результат. В
основі бізнес-вимог лежать бізнес-можливості, бізнес-мети, критерії успіху та
положення про концепцію .
Питання бізнес-вимог повинні вирішуватись до остаточного визначення
функціональних та нефункціональних вимог (рис.2.1). Положення про рамках та
обмеження проекту дуже допомагає в обговореннях пропонованих функцій та
цільових випусків. Бізнес-вимоги є відправною точкою для прийняття рішень
про запропоновані зміни та покращення вимог. Ми рекомендуємо представляти
бізнес-цілі, концепцію та межі на всіх семінарах зі збору вимог, щоб у команді
могли швидко зрозуміти, чи є запропонована вимога в рамках проекту/
Бізнес-вимоги визначають контекст і дозволяють вимірювати переваги, які
організація очікує отримати від реалізації проекту.
Організації не повинні ініціювати проект без чіткого розуміння користі,
яку він принесе для бізнесу. Визначайте вимірювані орієнтири на основі бізнес-
цілей, після чого визначайте критерії успіху, який дозволять оцінювати, чи ви на
шляху досягнення цих цілей.
Бізнес-вимоги можуть виходити від фінансових проектів замовників, топ-
менеджерів, менеджерів з маркетингу або відповідальних за концепцію
продукту. Проте визначити та донести бізнес-переваги буває непросто. Члени
команди не завжди впевнені у тому, яке завдання проекту. Іноді куратори не
хочуть визначати мету у вигляді, що піддається з мірянню, щоб потім не нести
відповідальність за їх досягнення.
Може бути кілька заінтересованих осіб, які не згодні з цілями. Бізнес-
аналітик повинен забезпечити, щоб бізнес-вимоги визначали правильні

Сторінка 1 з 15
 Business Requirements Specification
[Додайте Ім’я Інститут/Факультету]
’

заінтересовані особи та організувати збір, пріоритизацію та вирішення

конфліктів. Карл Вігерс (Karl Wiegers, 2006) пропонує низку питань, які повинен
ставити бізнес-аналітик при збиранні бізнес-вимог.

Рисунок 2.1. Вимоги до ПЗ [https://www.netsolutions.com/insights/business-and-

functional-requirements-what-is-the-difference-and-why-should-you-care/]

Бізнес-переваги повинні представляти реальну користь для кураторів і

клієнтів проекту. Наприклад, злиття двох систем в одну не є розумною бізнес-
метою. Клієнтам байдуже, чи використовують вони одну, п'ять чи десять систем
— їх цікавлять завдання, такі як підвищення доходів або зниження витрат. Злиття
двох систем може бути частиною рішення, але саме по собі воно рідко є бізнес-
метою. У проектів із забезпечення виконання вимог регулюючих органів також
є ясні бізнес-мети. Часто цілі формулюються як завдання уникнути ризиків,
наприклад ризику судового переслідування чи припинення роботи.
 Business Requirements Specification
[Додайте Ім’я Інститут/Факультету]
’

2.1.2 Концепція продукту та межі проекту

Концепція та межі — два базові елементи бізнес-вимог. Концепція
продукту (product vision) стисло описує кінцевий продукт, який досягне заданих
бізнес-цілей. Цей продукт може повністю задовольняти бізнес-вимоги або бути
тільки частиною рішення. Концепція описує, що продукт є зараз і яким він стане
згодом. Вона забезпечує контекст для прийняття рішень протягом життєвого
циклу продукту та вибудовує роботу всіх зацікавлених осіб в одному напрямку.
Межі проекту (project scope) показують, яку частину кінцевої концепції продукту
буде спрямований поточний проект чи ітерація. У положенні про межі визначено
межу між тим, що входить у проект і тим, що залишається зовні.
Концепція продукту змінюватиметься відносно повільно при визначенні з
часом стратегії продукту чи розвитку бізнес-цілей. Кордони ж належать до
певного проекту або його ітерації, в яких реалізуються можливості продукту.
Кордони динамічніші, ніж концепція, оскільки за цікаві особи змінюють вміст
кожної версії відповідно з обмеженнями графіка, бюджету, ресурсів та якості.
Кордони поточного випуску повинні бути чітко визначені, але межі майбутніх
випусків, тим менш чітко визначені, чим дальша перспектива розглядається.
Завдання команди полягає в управлінні кордонами конкретного проекту
розробки або поліпшення як певним підмножиною стратегічної концепції
продукту.
Документ про концепцію та межі (vision and scope document) збирає бізнес-
вимоги в єдиний документ, який готує основу для подальшої розробки продукту.
У деяких організаціях з цією ж метою створюють статут проекту (Wiegers, 2007)
або положення про бізнес-завдання. В організаціях, що створюють ПЗ на продаж,
часто створюють документ основних ринкових вимог (market requirements
document, MRD). У ньому більш детально, ніж у документі про концепцію та
межі, розглядаються цільові сегменти ринку та питання комерційного успіху
продукту. Власником документа про концепцію та межі вважається куратор
проекту, той, хто фінансує проект, або має аналогічну відповідальність. Бізнес-
аналітик може разом з цією людиною розробляти документ про концепцію та
межі. Інформація, що стосується бізнес-вимог, повинна надходити від осіб, які
чітко розуміють, чому вони взялися за проект. Це може бути клієнт або топ-
менеджер організації, що розробляє продукт, відповідальний за концепцію,
менеджер по продукту, експерт предметної галузі або фахівці відділу
маркетингу.
Документ концепції та кордонів визначає межі на високому рівні, а
подробиці кордонів представлені базовими вимогами окремих випусків,
визначених командою. Великі нові проекти повинні мати завершений документ
концепції та кордонів та специфікацію вимог (SRS) (рис. 2.2). Кожна ітерація,
випуск або проект з поліпшення продукту може включати власне положення про
 Business Requirements Specification
[Додайте Ім’я Інститут/Факультету]
’

межі документації вимог до проекту, при цьому створювати окремий документ

концепції та кордонів необов'язково.

Рисунок 2.2 – Розробка вимог до ПЗ [https://asana.com/ru/resources/business-

requirements-document-template]

2.1.3 Рекомендації до формулювання бізнес-вимог

Проекти запускаються з повним переконанням, що новий продукт зробить
світ для когось кращим та забезпечить прибуток. Бізнес-вимоги описують
основні переваги, які нова система дасть її замовникам, покупцям та
користувачам. Бізнес-вимоги безпосередньо впливають на те, які користувацькі
вимоги будуть реалізовані і в якій послідовності.
Вихідні дані підсумовують обґрунтування та зміст нового продукту або
зміни, які потрібно внести до існуючого продукту. Тут поміщають загальний
опис передісторії або ситуації, внаслідок чого було прийнято рішення про
створення продукту.
Для корпоративної інформаційної системи описують бізнес-завдання, яке
вирішується за допомогою цього продукту, або бізнес-процеси, для поліпшення
яких потрібен продукт, а також середовище, в якому система буде
 Business Requirements Specification
[Додайте Ім’я Інститут/Факультету]
’

використовуватися. Для комерційного продукту описують існуючі ринкові

можливості та ринок, на якому продукту доведеться конкурувати з іншими
продуктами. Цей розділ може містити порівняльну оцінку існуючих продуктів та
можливих рішень, вказуючи, у чому полягає привабливість продукту та його
переваги. Опишіть дачі, які не вдається дозволити без пропонованого рішення.
Покажіть, наскільки він відповідає тенденціям ринку, розвитку технологій чи
корпоративної стратегії. Стисло опишіть інші технології, процеси або ресурси,
необхідні для задоволення клієнта.
Опишіть потреби типових клієнтів чи цільового ринку. Уявіть завдання
клієнта, які вирішуватиме новий продукт. Надайте приклади того, як клієнти
використовуватимуть продукт. Вкажіть всі відомі критичні вимоги до якості або
інтерфейсів, але не згадуйте особливості реалізації та дизайну.
Бізнес-цілі підсумовують важливі переваги бізнесу, що надаються
продуктом, у кількісному та вимірюваному вигляді. Банальності («стати
компанією світового класу») і нечітко сформульовані поліпшення («забезпечити
високий рівень сервісу для клієнтів») не можна вважати ні корисними, ні
піддаються перевірці.
Організації зазвичай роблять проект на вирішення завдання чи
використання наявної можливості. Модель бізнес-цілей відображає ієрархію
пов'язаних бізнес-проблем та вимірюваних бізнес-цілей. Проблеми описують,
що не дозволяє організації досягти необхідних орієнтирів в даний час, тоді як
бізнес-мети визначають способи вимірювання досягнення цих орієнтирів.
Завдання та цілі взаємопов'язані: розуміння однієї розкривають суть другої.
Маючи набір бізнес-цілей, поставте запитання: «Що заважає нам досягти цього
орієнтиру?», щоб визначити більш детальне бізнес-завдання.
Або можна повернутися назад, запитавши: «Чому нам взагалі важливий
цей орієнтир?», щоб краще зрозуміти бізнес-завдання чи можливість верхнього
рівня. За наявності бізнес-завдання запитайте себе: «Як визначити, що завдання
вирішено?», щоб визначити ціль, що вимірюється. Процес виконується
ітеративно шляхом пересування по ієрархії задач і цілей, поки не вийде список
функцій, які дозволять вирішити задачі для досягнення цілей.
Бізнес-цілі іноді неможливо виміряти, доки не завершиться проект. В
інших випадках досягнення бізнес-цілей може залежати від інших проектів. Але
важливо оцінити успіх конкретного проекту. Критерії успіху вказують, чи є
проект на шляху досягнення бізнес-цілей. Ці критерії можуть визначатися під
час тестування або після випуску продукту.
Складіть стисле положення про концепцію проекту, що узагальнює
довгострокові цілі та призначення нового продукту. У цьому документі слід
відобразити балансовану концепцію, яка задовольняє різних заінтересованих
осіб. Вона може бути дещо ідеалістичною, але має ґрунтуватися на існуючих або
передбачуваних ринкових факторах, архітектурі підприємства, стратегічному
напрямку розвитку корпорації або обмеженнях ресурсів.
 Business Requirements Specification
[Додайте Ім’я Інститут/Факультету]
’

Далі показаний шаблон, що складається з ключових слів, які чудово

підходять для документа про концепцію продукту:
• Для [цільова аудиторія покупців];
• Який [положення про потреби чи можливості];
• Ця (цей) [ім'я продукту];
• Є [категорія продукту];
• який(а) [основні функції, ключова перевага, основна причина для покупки
або використання];
• На відміну від [основний конкуруючий продукт, поточна система або
поточний бізнес-процес];
• Наш продукт [положення про основну відмінність та перевагу нового
продукту].
Узагальнює найважливіші бізнес-ризики, пов'язані з розробкою - чи не з
раз роботою - цього продукту. До категорії ризиків входять ринкова конкуренція,
тимчасові фактори, прийнятність для користувачів, проблеми, пов'язані з
реалізацією, та можливі негативні фактори, що впливають на бізнес. Бізнес-
ризики відрізняються від ризиків проекту, які зазвичай пов'язані з доступністю
ресурсів та особливостями технологій. Оцініть можливі втрати від кожного
фактора ризику, ймовірність його виникнення, вашу здатність контролювати
його, а також визначте всі можливі дії щодо пом'якшення ситуації.
Припущення (assumption) — це твердження, яке передбачається вірним у
відсутності знань чи доказів іншого. Бізнес-припущення тісно пов'язані з бізнес-
вимогами. Неправильні припущення можуть не дозволити досягти поставлених
бізнес-цілей. Якщо виявиться, що ті чи інші припущення не виправдалися,
можете змінити межі або графік проекту або запустити інші проекти, щоб
досягти інших цілей.
Задокументуйте всі припущення, зроблені заінтересованими особами,
коли вони обмірковували проект і створювали цей документ про концепцію та
межі. Часто припущення одних осіб не поділяють інші сторони. Якщо ви
запишите їх і перегляньте пізніше, то уникайте можливої плутанини та
погіршення ситуації в майбутньому.
Задокументуйте найважливіші залежності проекту від зовнішніх факторів
— зміни галузевих стандартів або приписів регулюючих органів, інших проектів,
сторонніх постачальників або партнерів з розробки.
Припущення та залежності бізнесу можуть перетворитись на ризики, які
повинен регулярно відстежувати менеджер проекту. Порушення залежностей -
популярна причина затримок проекту. Опишіть можливі наслідки того, що
припущення виявляться хибними або залежно від порушення, щоб зацікавлені
особи могли зрозуміти, чому це так важливо.
Для проекту з розробки ПЗ слід визначити його рамки та обмеження. Вам
потрібно вказати, що може робити система, що не може. Багато проектів
страждають на «розпухання кордонів» — різке зростання через активне
 Business Requirements Specification
[Додайте Ім’я Інститут/Факультету]
’

розширення функціональності продукту. Перший крок на шляху приборкання

розпухання кордонів — визначення рамок проекту. Межі проекту визначають
концепцію та коло дії запропонованого рішення.
В обмеженнях вказуються певні можливості, які не будуть включені до
продукту. Рамки та обмеження допомагають встановити реалістичні очікування
заінтересованих осіб, тому що інколи клієнти запитують функції, які надто
дорогі або виходять за передбачувані межі продукту.
Рамки проекту можуть представлятися різними способами На найвищому
рівні кордону визначаються, коли клієнт вирішує, які бізнес-мети переслідувати.
На низькому рівні кордону визначаються на рівні функцій, історій користувача,
варіантів використання або подій і реакції на них. Зрештою межі визначаються
через набір функціональних вимог, які планується реалізувати у певному
випуску чи ітерації. На кожному рівні кордону не повинні виходити за рамки
більш високого рівня. Наприклад, користувацькі вимоги, що перебувають у
межах, повинні відповідати бізнес-цілям, а функціональні вимоги —
користувальницьким вимогам у заданих межах.
Бізнес-вимоги повинні визначатися у всіх проектах розробки програмного
забезпечення незалежно від моделі розробки. Бізнес-мети описують очікувану
вигоду від проекту, а в проекті гнучкої розробки вони використовуються для
полегшення визначення пріоритетів резерву (backlog), щоб досягти
максимальної цінності для бізнесу в ранніх ітераціях. Критерії успіху треба
визначити так, щоб після розгортання можна було виміряти успіх і відповідним
чином скоригувати резерв проекту. Положення про концепцію містить
довгостроковий план — те, чим має стати продукт після завершення всіх
ітерацій.
Для наочного представлення меж проекту найчастіше використовують
контекстні діаграми, карти екосистеми, дерева функцій та списки подій. Але
використовуються й інші методи. Виявлення бізнес-процесів також допомагає
визначати межі проекту. Діаграми варіантів використання дозволяють
проілюструвати кордон між варіантами використання та дійовими особами.

2.2 ПРАКТИЧНА ЧАСТИНА

Завдання до лабораторної роботи
1. Вивчити теоретичний матеріал, що надано у першій частині.
2. Сформулювати основне бачення програмного забезпечення (ПЗ) за
темою дипломної роботи (наукової роботи) студента.
3. Розробити специфікацію бізнес-вимог згідно шаблону, наданому у
додатку.
4. Скласти звіт з лабораторної роботи, включаючи специфікацію бізнес-
вимог, яка затверджується керівником дипломної роботи
 Business Requirements Specification
[Додайте Ім’я Інститут/Факультету]
’

ДОДАТОК
Шаблон специфікації вимог

[Ім’я проекту]

Затвердження
Власник Затверджено/ Не Підпис Заголовок Дата
бізнесу/Зацікавлена затверджено
сторона

Список розповсюджувачів
Усі, хто перечисленні нижче повинні допомогти розповсюдженню ресурсів та усвідомлюють що
наступну інформацію так детально розглянуто з метою погодження.

Ім’я Посада

Автор: [Ім’я], Бізнес аналітик, ITS

Версія:
Дата: 21 November 2022
BUSINESS REQUIREMENTS SPECIFICATION – [Назва проекту]

Контроль версій
Версія Ім’я Заголовок Контактна Дата Підсумок Змін
Інформація
[Версія] [Ім’я автора] [Заголовок] [Email Адреса] [Дата] [IДодайте опис змін, що буде
додано до цього документу, а
також причину цих змін]

Деталі Документа
Ім’я Документа Місцезнаходження Документа

Сторінка 9 з 15
BUSINESS REQUIREMENTS SPECIFICATION – [Назва проекту]

Зміст
1. Вступ ............................................................................ Ошибка! Закладка не определена.
1.1. Призначення ................................................................ Ошибка! Закладка не определена.
1.2. Цільова аудиторія ....................................................... Ошибка! Закладка не определена.
1.3. Визначення, термінологія, скорочення та абревіатури ..................................................... 11
1.4. Припущення ................................................................ Ошибка! Закладка не определена.
1.5. Залежності ........................................................................................................................... 11
1.6. Обмеження .......................................................................................................................... 11
1.7. Підхід до збору вимог ......................................................................................................... 12
1.8. Контекст бізнесу .......................................................... Ошибка! Закладка не определена.
1.8.1. Контекстна діаграма.................................................. Ошибка! Закладка не определена.
2. Сфера застосування ................................................... Ошибка! Закладка не определена.
2.1. В межах проекту .......................................................... Ошибка! Закладка не определена.
2.2. За межами проекту ............................................................................................................. 12
3. Ділова ціль / Завдання ........................................................................................................ 13
4. Ключові зацікавлені сторони .............................................................................................. 13
5. Моделі бізнес-процесів ....................................................................................................... 13
6. Вимоги розміщення пріоритетів.......................................................................................... 13
7. Вимоги до бізнесу (BR) ....................................................................................................... 14
8. Вкладення.................................................................... Ошибка! Закладка не определена.

Сторінка 10 з 15
BUSINESS REQUIREMENTS SPECIFICATION – [Назва проекту]

1. Вступ
1.1. Призначення
Призначення цього документа уточнити вимоги до бізнесу, що було надано зацікавленим сторонам для
проекту <Назва проекту>……

1.2. Цільова аудиторія

Цей документ призначений для читання:

• Спонсорами проекту, Володарями бізнесу та Делегатами проекту та усіма іншими ключовими

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

1.3. Визначення, термінологія, скорочення та абревіатури

Визначення, термінологія, скорочення та абревіатури, що використовуються в межах цього проекту,
містяться у цій таблиці:
Визначення, термінологія, Визначення/Опис
скорочення та абревіатури
я.н. АНУ Австралійський національний університет

ГМІ Головний менеджер з інформатизації

ПІТ Послуги з інформаційних технологій

1.4. Припущення
[Занесіть припущення, що були зроблені]

1.5. Залежності
[Занесіть залежності, що були виявлені]

1.6. Обмеження
[Занесіть обмеження, що існують]

Сторінка 11 з 15
BUSINESS REQUIREMENTS SPECIFICATION – [Назва проекту]

1.7. Підхід до збору вимог

[Уточніть підхід, що було використано до збору вимог та задокументуйте вимоги, наприклад:
• Інтерв'ювання зацікавлених сторін
• Проведення семінарів для зацікавлених сторін
• Розроблено процеси “As Is”
• Розроблено шаблони “To Be” бізнес процесів
• Підсумок “To Be” процесів, що було обговорено на семінарах зацікавлених сторін]

1.8. Контекст бізнесу

[Надайте огляд бізнес плану та причини для того, щоб проект почав розроблятися.]

1.8.1. Контекстна діаграма

[Надайте інформацію про контекстну діаграму (оглядово)]

2. Сфера застосування
2.1. В межах проекту
Для досягнення цілей проекту, поставлених бізнесом, та реалізації максимально можливих
матеріальних та нематеріальних переваг (зисків) потрібно буде здійснити широкий спектр заходів,
включаючи:

2.2. За межами проекту

Далі розглядаються цілі поза сферою застосування:

Сторінка 12 з 15
BUSINESS REQUIREMENTS SPECIFICATION – [Назва проекту]

3. Ділова ціль/Завдання
Для цілей проекту та завдань, будь ласка, зверніться до документа Економічне обґрунтування <Ім’я
документа>. (Будь ласка зверніться до секції з назвою «Пов’язані документи», щоб знайти шлях до
документа)

4. Ключові зацікавлені сторони

Для більш детальної інформації про сполучення зацікавлених сторін, будь ласка, зверніться до
документу <Ім’я документа>. (Будь ласка зверніться до секції з назвою «Пов’язані документи», щоб
знайти шлях до документа)

5. Моделі бізнес-процесів
[Або вставте в цей документ моделі бізнес-процесів як додаток у розділі 8, або посилайтеся на них як
на відповідний документ, включіть наступне ....]
Для моделей ‘As Is’ і ‘To Be’ бізнес процесів будь ласка зверніться до документу <Ім’я документа>.
(Будь ласка зверніться до секції під назвою «Пов’язані документи» щоб знайти шлях до документа)
АБО
Для моделей ‘As Is’ і ‘To Be’ бізнес процесів зверніться до секції 8, «Вкладення»

6. Вимоги розміщення пріоритетів

Вимоги будуть розміщені згідно пріоритетам, що базуються на техніці MoSCoW, котра розділяє вимоги
на наступні категорії:

Рейтинг пріоритетів Опис

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

Сторінка 13 з 15
BUSINESS REQUIREMENTS SPECIFICATION – [Назва проекту]

7. Вимоги бізнесу (BR)

Посилання Вимоги Пріоритет
BR01
BR02
BR03

BR04

BR05
BR06

BR07

BR08

BR09

BR10

BR11

BR12

BR13

BR14

BR15

BR16

BR17

BR18

BR19

BR20

BR21

Сторінка 14 з 15
BUSINESS REQUIREMENTS SPECIFICATION – [Назва проекту]

8. Вкладення
[Де це необхідно, прикріпіть документи, що були розроблені разом з іншими інструментами, які
формують частину або підтримують вимоги специфікації.]

Сторінка 15 з 15