Бізнес-вимоги: розробка та приклади оформлення

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

Визначення

Плутанина в термінології виникає з трьох основних причин:

1. Звичайною практикою є позначення цілей або очікуваних вигод як бізнес-вимога.
2. Люди, як правило, використовують цей термін для позначення характеристик продукту, системи, програмного забезпечення, які передбачається створити.
3. Широко поширена модель стверджує, що ці два типи заявок відрізняються лише рівнем деталізації або абстракції — де бізнес-вимоги є високорівневими, часто розпливчастими і розкладаються на детальні заявки до компоненту.

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

Оновлення продукту

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

Акценти процесу

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

Огляд

Бізнес-вимоги в контексті розробки програмного забезпечення або його життєвого циклу-це концепція виявлення та документування будь-яких Користувачів. Наприклад, таких як клієнти, співробітники та постачальники, на ранніх етапах циклу створення системи для керівництва проектуванням майбутнього. Заявки часто фіксуються аналітиками. Саме вони аналізують вимоги бізнес-процесу і часто вивчають його «як є"для визначення цільового»майбутнього".

Склад заявок

Вимоги бізнес-процесу часто включають:

1. Контекст, область і фон, в тому числі і причини змін.
2. Ключові зацікавлені сторони, які мають вимоги.
3. Фактори успіху для майбутнього або цільового стану.
4. Обмеження, накладені бізнесом або іншими системами.
5. Моделі та аналіз процесів, які часто використовують блок-схеми для представлення всього " як є».
6. Логічна модель даних та посилання на Словник.
7. Глосарії ділових термінів та місцевий жаргон.
8. Діаграми потоків даних для ілюстрації того, як вони проходять через інформаційні системи (на відміну від блок-схем, що зображують алгоритмічний потік бізнес-операцій).

Роль

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

Повнота

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

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

Прообраз

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

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

Розробка

Важливо розпізнавати зміни в заявках, документувати їх і оновлювати. Однак ділові запити, як правило, змінюються не так сильно, як усвідомлення їх. Бізнес-вимога може бути присутнім, але не бути визнаним або зрозумілим зацікавленими сторонами, аналітиками та командою проекту.

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

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

Приклади оформлення

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

Труднощі

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

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

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