Бізнес-вимоги — це специфікації, які після надання забезпечують цінність і описують характеристики пропонованої системи, з точки зору кінцевого користувача. І також називаються перерахуванням заявок заінтересованих сторін. Продукти, програмне забезпечення і процеси є способами, як поставити і задовольнити потреби підприємства. Отже, бізнес-вимоги часто обговорюються в контексті розробки або придбання програмного забезпечення або інших систем.
Визначення
Плутанина в термінології виникає по трьох основних причин:
- Звичайною практикою є позначення цілей або очікуваних вигод як бізнес-вимог.
- Люди, як правило, використовують цей термін для позначення характеристик продукту, системи, програмного забезпечення, які передбачається створити.
- Широко поширена модель стверджує, що ці два типи заявок відрізняються тільки рівнем деталізації або абстракції — де бізнес-вимоги є високорівневими, часто розпливчастими і розкладаються на докладні заявки до компоненту.
Такого непорозуміння можна уникнути, якщо визнати, що дане поняття не є цілями, а скоріше відповідає їм (тобто забезпечує цінність) при їх задоволенні. Бізнес-вимоги не розкладаються в продукт, системи і програмне забезпечення. Скоріше, все відбувається навпаки. Продукти та їх заявки являють собою відповідь на бізнес-вимоги — імовірно, щоб задовольнити їх. Дане поняття існує у виробничому середовищі і повинно бути виявлено, тоді як попити до продукту визначені людиною. Вимоги до бізнес-плану не обмежуються існуванням високого рівня, а повинні бути зведені до деталей. Незалежно від величини деталізації, заявки завжди забезпечують цінність, коли задоволені.
Оновлення продукту
У проектах розробки систем та програмного забезпечення вимог малого бізнесу, зазвичай, необхідні повноваження зацікавлених сторін. Саме вони призводять до створення або оновлення продукту. Бізнес-вимоги до системи і програмного забезпечення зазвичай складаються з функціональних і нефункціональних заявок. Звичайно ж, зазвичай вони визначаються в поєднанні з першим варіантом можливостей продукту. Другий часто фактично відображає оформлення бізнес-вимог, які іноді розглядаються як обмеження. Вони можуть включати необхідні аспекти продуктивності або безпеки, чинних на виробничому рівні.
Акценти процесу
Заявки часто перераховані в офіційних документах. Акцент у них робиться на процесі або діяльності точного планування та розробки бізнес-вимог, а не на тому, як цього досягти. Цей параметр зазвичай делегується специфікацією або документом системних заявок чи іншого варіанту. Може виникнути плутанина між ними, якщо не враховувати всі відмінності. Отже, багато офіційні документи фактично описують вимоги до продукту, системи чи програмного забезпечення.
Огляд
Бізнес-вимоги в контексті розробки програмного забезпечення або його життєвого циклу — це концепція виявлення та документування будь-яких користувачів. Наприклад, таких як клієнти, співробітники та постачальники, на ранніх етапах циклу створення системи для керівництва проектуванням майбутнього. Заявки часто фіксуються аналітиками. Саме вони аналізують вимоги бізнес-процесу і часто вивчають його «як є» для визначення цільового «майбутнього».
Склад заявок
Вимоги бізнес-процесу часто включають в себе:
- Контекст, область і фон, в тому числі і причини змін.
- Ключові зацікавлені сторони, у яких є вимоги.
- Фактори успіху для майбутнього або цільового стану.
- Обмеження, що накладаються бізнесом або іншими системами.
- Моделі і аналіз процесів, часто використовують блок-схеми для подання за все «як є».
- Логічна модель даних та посилання на словник.
- Глосарії ділових термінів та місцевий жаргон.
- Діаграми потоків даних для ілюстрації того, як вони проходять через інформаційні системи (на відміну від блок-схем, що зображують алгоритмічний потік бізнес-операцій).
Ролі
Самий популярний формат для запису бізнес-вимог — це документ. Мета їх полягає в тому, щоб визначити, які результати будуть від необхідні системи, однак, вона може бути в кінцевому підсумку розроблена без додаткових умов. Отже, документи доповнюються довідковим матеріалом, який деталізує продуктивність технології та очікування інфраструктури, включаючи будь-які професійні вимоги, що ставляться до якості обслуговування.Це, наприклад, продуктивність, ремонтопридатність, адаптивність, надійність, доступність, безпека і масштабованість.
Повнота
Прототипування на ранній стадії тестування дозволяє оцінити повноту і точність виявлених бізнес-вимог. Зацікавлені сторони проходять процедуру першими, щоб допомогти визначити структуру. І результат направляється командам розробників бізнес-вимог проекту, які будують систему. Інші зацікавлені сторони тестують і оцінюють остаточно розгорнуту проекцію. Ясність вимагає відстеження заявок і їх рішення з формальним процесом визначення відповідного шаблону.
Обсяг бізнес-вимог не обов’язково обмежений стадією дефініції того, що повинно бути побудоване як система. Це виходить за рамки того, щоб передбачити, як керувати і підтримувати діючу стратегію. І забезпечувати її постійне відповідність бізнес-цілям. Документ вимог повинен постійно переглядатися контрольованим чином. Наявність стандартизованого формату або шаблонів, розроблених для конкретних бізнес-функцій і доменів, може забезпечити повноту запитів, крім збереження сфокусованості області.
Прообраз
Незважаючи на те, що зазвичай вважається засобом оцінки вимог, прототипування зазвичай переключає увагу на створюваний продукт або систему. Прототипи — це працююче програмне забезпечення, що означає, що вони складаються з трьох етапів (заявки, інженерне або технічне проектування і реалізація), віддалених від бізнес-вимог. І це також попередні версії, які розробник має намір впровадити.
Оскільки прототипи є досить конкретними, зацікавлені сторони, які випробують їх, можуть дати більш значущі відгуки про деякі аспекти того, що створює розробник, що є інтерпретацією способу задоволення. Більш того, графічний інтерфейс користувача підкреслюється, а внутрішня частина — це ярлики. Вони складають основну частину програмної логіки, і саме там будуть задоволені більшість бізнес-вимог. Іншими словами, проблеми, які виявляють прототипи, навряд чи пов’язані з запитами.
Розробка
Важливо розпізнавати зміни в заявках, документувати їх і оновлювати. Однак ділові запити, як правило, змінюються не так сильно, як усвідомлення їх. Бізнес-вимога може бути присутнім, але не бути визнано або зрозуміле зацікавленими сторонами, аналітиками та командою проекту.
Зміни, як правило, відображають передбачувані способи задоволення неадекватно певних матеріалів. Велика частина труднощів, пов’язаних з виконанням бізнес-вимог, насправді відображає загальну практику, спрямовану майже на всі зусилля, пов’язані з ними, на те, що насправді являє собою високорівневий дизайн продукту, системи або програмного забезпечення. Це пов’язано з нездатністю спочатку адекватно визначити бізнес-вимоги, щоб забезпечити цінність.
Практики розробки зазвичай продовжують переглядати продукт до тих пір, поки вони в кінцевому підсумку не «повернуться» до рішення, яке, здається, виконує те, що необхідно, то є, мабуть, відповідає запитам виробництва. Непрямі методи проб і помилок для визначення бізнес-вимог є основою для більшої частини «ітеративної розробки», включаючи популярні методи, які рекламуються як «кращі практики».
Приклади оформлення
Шаблони допомагають оперативно запитувати конкретні теми, які часто можуть мати відношення до запитів. Вони можуть створювати стандартизовану документацію, що стосується вимог бізнесу, що може полегшити розуміння. Шаблони не гарантують точність або повноту запитів. Часто неправильно використовуються приклади негативно впливають на дослідження, оскільки вони мають тенденцію сприяти поверховості і головним чином механічного визначенню без осмисленого аналізу.
Труднощі
Бізнес-вимоги часто передчасно посилюються із-за великої бази зацікавлених сторін, що беруть участь у їх визначенні, де існує ймовірність конфлікту інтересів. Процес управління та досягнення консенсусу може бути делікатним і навіть політичним за своєю природою. Менш складна, хоча і поширена завдання — це розподілені групи з зацікавленими сторонами в різних географічних точках. Природно, що торговий персонал ближче до своїх клієнтів, а виробничий – до відповідним одиницям. Фінанси та управління працівниками, включаючи вище керівництво, ближче до зареєстрованої штаб-квартирі.
Бізнес-вимоги, приміром, потрібні для системи, в якій беруть участь користувачі, що займаються продажами і виробництвом. Вона може зіткнутися з конфліктом цілей — одна сторона зацікавлена в наданні максимальної кількості функцій, а інша зосередиться на самій низькій вартості виробництва. Такі ситуації часто закінчуються консенсусом з максимальними можливостями для розумної, вигідної ціни і розподілу.
Щоб вирішити ці проблеми, участь зацікавлених сторін на ранній стадії досягається шляхом демонстрації прототипу і спільної роботи. Практичні семінари як у вигляді організованих сесій, так і простих дискусій, допомагають досягти консенсусу, особливо щодо делікатних вимог бізнесу і там, де існує потенційний конфлікт інтересів. Складність процесу є важливим чинником. Це може потребувати спеціальних знань, необхідних для розуміння правових або нормативних вимог, внутрішніх керівних принципів, таких як брендинг або корпоративні зобов’язання щодо соціальної відповідальності. Аналіз полягає не тільки в тому, щоб вловити «що» з бізнес-процесу, але також «як» представити його контекст.
