Как да организирате изискванията като бизнес анализатор

Бизнес изискването е официален документ, който обхваща нуждите на заинтересованите страни за даден проект или продукт. Няма единен стандартен формат за представяне на бизнес изискванията, но всяка версия трябва да обхваща продукта или проекта достатъчно подробно, за да може да бъде обсъден, анализиран, документиран и валидиран.

Бизнес изискване може да бъде представено по един от следните начини:

• Таблица или електронна таблица
• Диаграма (работен процес)
• Графика
• Модел (диаграма на обект-връзка)
• Прототип или симулация
• Структурирано изречение или текстов шаблон

Как да организираме и представим бизнес изискване

По-долу са стъпките за писане и организиране на изискванията като Бизнес анализатор.

Стъпка 1) Категоризирайте изискванията.

• Поставете всяко изискване в категорията, към която принадлежи.
• Техническите заинтересовани страни трябва да видят категория технически изисквания, а нетехническите заинтересовани страни трябва да видят категория бизнес или общи изисквания.
• Всяка организация трябва да реши кои категории отговарят на нейните собствени стандарти.
• Категоризацията може да се основава и на типа изискване – функционално спрямо бизнес – въпреки че това разделение не е подходящо за всеки проект.

Стъпка 2) Подредете изискванията.
Съберете и подредете изискванията в логичен ред, така че заинтересованите страни да могат лесно да се ориентират в документа и да забележат липсващите елементи.

Стъпка 3) Подгответе списък.
Подгответе списък с изисквания, групирани по заинтересовани страни, които трябва да ги одобрят.

Например, заинтересована страна с технически опит ще се интересува само от техническия аспект на продукта.

Стъпка 4) Използвайте уникални идентификатори.
If tracСъгласуването на изискванията един към друг е трудно, използвайте уникални идентификатори, за да направите tracпо-лесна удобство.

Стъпка 5) Представете изискванията по предпочитания от заинтересованите страни начин.
Може да се наложи да представите едно и също изискване в различни формати за различните заинтересовани страни – едната предпочита графичен изглед, докато другата предпочита структурирани изречения.

Стъпка 6) Подгответе съдържание.
Създайте съдържание за всички изисквания. Това помага на заинтересованите страни track и ги намерете бързо.

Стъпка 7) Използвайте инструменти за бизнес анализ.
употреба Инструменти за бизнес анализ които помагат за последователното представяне и категоризиране на изискванията в различните издания.

Стъпка 8) Организирайте документите за изискване по поток на процеса.
Премахнете ненужните изисквания от документа и организирайте оцелелите според потока на процеса, който те поддържат.

Стъпка 9) Карта на изискванията.
Свържете всяко изискване, което събирате, с конкретна стъпка от работния процес, така че проверяващите да могат да свържат изискването с работния процес, който то поддържа.

Стъпка 10) Използвайте таблица и точки.
Използвайте таблици, за да представите сложни изисквания, и точки, за да подчертаете ключовите аспекти на всяко от тях.

Полезни съвети за писане и представяне на документ с бизнес изисквания

За по-добро представяне и tracкрал на бизнес изискванията, следните съвети са полезни за всеки бизнес анализатор (бакалавър).

• Категоризирането на изискванията отнема време, затова е необходимо да се определи стандартен набор от категории, които бизнес асистентите, заинтересованите страни, експертите по предмета и техническите екипи могат да използват повторно в различните проекти, вместо да се измислят нови всеки път.
• Подгответе всяко изискване в контекста на неговата аудитория. Разберете ключовите играчи, влиятелни лица и лица, вземащи решения (заинтересовани страни, технически персонал, разработчици и т.н.).
• Дефинирайте едно по едно изискване. Всяко изискване трябва да бъде атомарно.
• Избягвайте двусмислие — не използвайте неясни определители като „и т.н.“ или „приблизително“ в описанието на изискването.
• Не цитирайте изискване, което все още не е дефинирано.
• Премахнете дублиращите се и противоречиви твърдения от документа.
• Разделете сложните изисквания на по-малки, управляеми и лесно преглеждаеми точки.
• Описвам какво системата ще го направи, не как ще го направи — внедряването е част от фазата на проектиране.

Популярни техники за визуализиране на бизнес изискванията

Стената от проза е най-бързият начин да загубите заинтересована страна. Бизнес анализаторите съчетават всяко текстово изискване с визуализация, така че намерението да е ясно от пръв поглед. Следните техники се появяват в Ръководството на BABOK и в повечето корпоративни практики за бизнес анализ.

• Модел и нотация на бизнес процеси (BPMN): Изобразява цялостни бизнес процеси с групи, канали, шлюзове и събития. BPMN е идеален за показване кой какво прави и кога.
• Диаграми на случаи на употреба и Descriptйони: Заснемане на взаимодействията между участници и система и резултатите, които всеки участник очаква. Подходящо за натрупани задачи, базирани на функции.
• Потребителски истории с критерии за приемане: Кратки твърдения от типа „Като... искам... така че...“, съчетани с критерии „Дадено-Когато-Тогава“. Форматът по подразбиране в agile екипите.
• Скейтбордове и макети: Екрани с ниска или средна прецизност, произведени в Figma, Балсамик или Axure които правят изискванията за потребителски интерфейс осезаеми за нетехнически заинтересовани страни.
• Диаграми на взаимовръзките между обекти (ERD): Покажете обектите на данни, които решението трябва да съхранява, и връзките между тях – което е от решаващо значение за изискванията за отчитане и интеграция.
• Диаграми на потока от данни (DFD): Tracкак данните се движат през процеси, хранилища и външни участници, особено в аналитични или интеграционни проекти.

Съобразете техниката с аудиторията: ръководителите реагират на карти на процесите и диаграми на пътя, разработчиците реагират на ERD и потребителски истории, а крайните потребители реагират на wireframes и прототипи.

Общи инструменти за организиране на документи с бизнес изисквания

След като броят на изискванията надхвърли няколко десетки, един Word документ спира да се мащабира. Бизнес анализаторите преминават към специално създадени инструменти, които поддържат базово определяне, преглед, tracефективност и контрол на промените. Следните са най-широко използваните в индустрията.

• Джира с Confluence: Стандартната комбинация за agile екипи. Изискванията са налични като епични модели и истории в Jira, подкрепени от Confluence страници, които съдържат BRD наратива и диаграмите.
• Джама Кънект: Корпоративна платформа, фокусирана върху управление на изискванията, базови линии и работа в реално време tracвъзможност за регулирани индустрии като медицински изделия и аерокосмическа индустрия.
• IBM Engineering Requirements ВРАТИ ЗА УПРАВЛЕНИЕ: Дългогодишен инструмент, използван в отбраната, автомобилната промишленост и критичните за безопасността системи, където всяко изискване трябва да бъде изпълнено tracвъзможно.
• Modern Requirements за Azure DevOps: Разширява Azure DevOps с преглед, одобрение, базова линия и експортиране в BRD стил на Word директно от работни елементи.
• Miro or Lucidchart: Инструменти за бяла дъска и диаграми, използвани за изготвяне на BPMN, ERD, потребителски пътешествия и бележки от семинари, които по-късно се използват за генериране на официалния BRD.
• Балсамик и Figma: Инструменти за wireframe и прототипи, които запазват изискванията за потребителския интерфейс визуални, вместо текстови.

Изберете набор от инструменти според мащаба на проекта и нуждите от одит. По-малките проекти могат да започнат с Confluence и Jira, докато регулираните програми обикновено се нуждаят от Jama или DOORS, за да задоволят... tracодити за надеждност.

Често срещани грешки при представяне на бизнес изисквания

Дори добре проучено изискване може да бъде отхвърлено, ако е представено лошо. Следните грешки се появяват в повечето анализи на бизнес асоциации (BA) и са тези, за които трябва да се внимава по време на прегледа.

• Смесване на какво и как: Хлъзганеping Детайлите за внедряването в декларацията за изискванията заключват екипа по проектиране в решение, преди анализът да е завършен.
• Неясно формулирана формулировка: Думи като „бърз“, „лесен за потребителя“ или „гъвкав“ не могат да бъдат тествани. Заменете ги с измерими критерии за приемане.
• Един формат за всяка заинтересована страна: Представянето на една и съща гледна точка на ръководители, разработчици и крайни потребители обикновено не устройва никого от тях. Приспособете формата към аудиторията.
• Липсващ tracвъзможност: Изисквания, които не са свързани с бизнес цели, дизайнерски елементи и тестови случаи, не могат да бъдат защитени, когато пристигне заявка за промяна.
• Без приоритизиране: Представянето на стотици изисквания без MoSCoW, претеглено оценяване или подобна рамка принуждава заинтересованите страни да спорят за обхвата, вместо за стойността.
• Претоварени документи: Натъпкването на всяка диаграма, лог и обосновка в един PDF файл от 200 страници скрива важните изисквания. Разделете BRD на логически раздели с ясно съдържание.
• Пропусниping подписване: Представянето на BRD без официално одобрение отваря вратата за разширяване на обхвата и обвиняване по-късно в процеса на изпълнение.

RevПреглеждането на BRD спрямо този списък преди всяка сесия със заинтересованите страни отчита повечето от проблемите, които водят до преработка в по-късни фази.

Въпроси и Отговори