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

Проектите рядко се провалят, защото никой не е записал изискванията. Провалят се, защото това, което е записано, е било твърде неясно, за да не може да се спори с него. Всички са подписали документ, че системата трябва да е „лесна за потребителя и бърза“, и четири месеца по-късно откриват, че са имали предвид три различни неща.

Документът с бизнес изисквания си струва да се напише, когато прави възможно несъгласието преди да започне изграждането, а не след това. Този шаблон е създаден за това: всяко изискване е номерирано, приоритизирано и снабдено с критерии за приемане, достатъчно конкретни, за да може да се спори с тях още сега.

Изтеглете шаблона за документ с бизнес изисквания

Безплатно, за редакция, без воден знак. Повечето екипи използват Word за документа и Excel за таблицата с изисквания, след като броят премине около тридесет.

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

Документът с бизнес изисквания, или BRD, описва от какво се нуждае бизнесът от даден проект и защо, преди някой да реши как да го изгради. Той дефинира проблема, обхвата, заинтересованите страни, самите изисквания и критериите, по които резултатът ще бъде оценяван.

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

Как да персонализирате този шаблон в Trupeer

Стъпка 1: Отворете секцията Templates

Отидете в секцията Templates от главната навигация.

Стъпка 2: Изберете и отворете шаблон

Кликнете върху който и да е шаблон, с който искате да работите, за да го отворите.

Стъпка 3: Разгънете изгледа на шаблона

Ако е необходимо, разгънете изгледа на шаблона, за да видите пълното оформление и детайлите ясно.

Стъпка 4: Редактирайте шаблона

Кликнете върху Edit, за да започнете да променяте избрания шаблон.

В редактора можете да:

• Добавяте нови секции

• Дефинирате или актуализирате правила за форматиране

• Добавяте лого и настройвате позицията му и свързаните настройки

Стъпка 5: Запазете персонализирания си шаблон

След като направите всички необходими промени, кликнете върху Save, за да запазите актуализирания шаблон като свой.

Стъпка 6: Преглед и фина настройка на шаблона

Когато искате да видите как изглежда вашият персонализиран шаблон, отворете Preview.

От екрана за преглед можете да продължите да правите корекции директно, ако е необходимо, като гарантирате, че шаблонът се показва точно както искате.

С шаблон за документ с бизнес изисквания можете да:

• Спестите часове при писане: Пропуснете празната страница със структура, използвана от опитни BA и PM.

• Съгласувате бизнес и технологии: Вградените секции свързват бизнес целите с функционалните изисквания.

• Останете в бранда: Приложете логото, шрифтовете и цветовете си с brand kit-а на Trupeer.

• Комуникирате ясно: Превърнете плътните BRD в видео разходки за преглед от заинтересованите страни.

• Стандартизирайте между проектите: Използвайте един и същ шаблон за BRD за всяка инициатива.

• Достигнете до глобални екипи: Превеждайте BRD на 65+ езика с едно кликване.

Защо ви е нужен документ с бизнес изисквания

• Обхватът става нещо, към което можете да посочите, вместо да го помните. Повечето спорове за обхвата са провали в документацията, а не недобросъвестност.

• Изискванията получават приоритети, така че когато времето не стига, режете целенасочено, вместо да отрязвате каквото остане.

• Предположенията се записват, което е моментът, в който някой забелязва, че грешното е записано.

• Критериите за приемане съществуват преди изграждането, така че „готово“ не се решава от този, който е най-шумен в края.

• Предаването оцелява след напускането на хора. Проектите, които губят своя бизнес анализатор по средата, са тези, при които BRD плаща за себе си изцяло.

• Доставчиците могат да оферират срещу нещо реално. Неясен BRD води до широка оферта и проект, натоварен с искания за промяна.

Какво включва документът с бизнес изисквания

• Контрол на документа: версия, автор, дата, разпространение и статус на одобрение.

• Резюме за ръководството: какво представлява проектът и защо, в един абзац.

• Бизнес цели, изразени като измерими резултати, а не като дейности.

• Контекст и формулировка на проблема: какво се случва в момента и какви са разходите.

• Обхват: какво е вътре и изрично какво е извън него.

• Заинтересовани страни: кой е засегнат, кой взема решения, кой подписва.

• Текущо състояние, такова каквото е в действителност.

• Бизнес изисквания, номерирани, приоритизирани, като всяко има критерии за приемане.

• Предположения, ограничения и зависимости.

• Рискове, с отговорници.

• Обобщение на разходите и ползите и очакваната възвръщаемост.

• График и ключови етапи.

• Критерии за успех за проекта като цяло.

• Речник, защото половината от всички спорове за изискванията са спорове за терминология.

• Блок за подписване.

• Приложения: карти на процесите, данни, екрани, подкрепящ анализ.

Структурата на шаблона

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

Как да напишете изискване, което издържа преглед

Това е цялото умение. Изискването е добре написано, когато двама души, които не са съгласни, и двамата разбират от прочита му, че не са съгласни.

Слабо: Системата трябва да е лесна за потребителя.
По-добре: Нов потребител трябва да може да подаде претенция без обучение, измерено чрез 8 от 10 тестови потребители, които завършват подаването самостоятелно за под 3 минути.

Слабо: Отчетите трябва да се зареждат бързо.
По-добре: Месечният обобщен отчет трябва да се визуализира за 4 секунди за набор от данни до 50 000 реда.

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

Слабо: Системата трябва да се интегрира с финанси.
По-добре: Одобрените претенции трябва да се публикуват в счетоводната система в рамките на 15 минути, включително код на разходен център и ДДС код, като неуспехите се записват и се опитват отново автоматично.

Моделът във всяко подобрение е един и същ. Назовете кой се нуждае от него, какво точно и при какво условие бихте се съгласили, че е постигнато. Думи, на които да не вярвате в собствените си чернови: лесна за потребителя, надеждна, безпроблемна, интуитивна, бърза, гъвкава, мащабируема, лесна. Всяка от тях крие решение, което някой ще вземе по-късно без вас.

Приоритизиране на изискванията с MoSCoW

Изискванията без приоритети по подразбиране стават задължителни, а първият натиск по графика принуждава произволни съкращения.

Дисциплината, която кара MoSCoW да работи: не повече от около 60% от изискванията трябва да са „Трябва да има“. Ако всичко е „Трябва да има“, имате списък с желания с колона за приоритет. А списъкът „Няма да има този път“ е най-ценният, защото е писменият запис на това, което съзнателно е отложено, а не забравено.

Таблицата с изискванията

Всяко изискване се нуждае от ID, защото „изискването за отчет“ е двусмислено в момента, в който има две. Източникът има значение, защото през четвъртия месец някой ще попита кой го е поискал, а „бизнесът“ не е отговор.

Матрица за проследимост

Проверката, че нищо не е било тихо пропуснато и че не се изгражда нищо без причина.

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

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

Съкратен работещ пример, за да видите нивото на конкретика.

Проект: Замяна на система за претенции за разходи. Версия: 1.2. Автор: Бизнес анализатор. Одобряващи: Финансов директор, IT директор, HR директор.

Бизнес цели. Да се намали средното време за възстановяване на претенция от 24 работни дни до 10. Да се намали времето на финансовия екип, отделяно за обработка на претенции, с 50%, като в момента са 14 часа седмично. Да се постигне 95% съответствие с политиката при подадени претенции, като в момента е 71%.

Формулировка на проблема. Претенциите се подават в електронна таблица и се изпращат по имейл. Маршрутизирането за одобрение е ръчно, разписките пристигат отделно и 29% от претенциите нарушават политиката, без да бъдат открити преди плащането. Финансът отделя приблизително 14 часа седмично за преследване, а възстановяването средно отнема 24 работни дни при ангажимент от 10 дни в наръчника за служители.

В обхвата. Подаване на претенции, заснемане на разписки, валидиране на политика, маршрутизиране за одобрение, публикуване в счетоводната система, уведомяване на служителите.
Извън обхвата. Съгласуване на корпоративна карта, задаване на километражни ставки, интеграция с заплати, миграция на исторически претенции извън 12 месеца.

Изисквания.

Предположения. Текущата организационна структура в HR системата е точна и се поддържа. Счетоводната система предоставя поддържан API. Лимитите на политиката няма да се променят по време на внедряването.

Ограничения. Бюджет от £85,000. Трябва да се пусне в експлоатация преди новата финансова година. Без допълнителни позиции във финансовия отдел.

Рискове. Данните за отчетната линия в HR се оказват ненадеждни, отговорност на HR директора, смекчено чрез одит преди изграждането. Приемането от одобряващите е бавно, отговорност на финансовия директор, смекчено чрез обучение на мениджърите и паралелно изпълнение в продължение на две седмици.

Критерии за успех. Средното възстановяване е на или под 10 работни дни в рамките на един тримесечен период от пускането в експлоатация. Време за обработка във финансите на или под 7 часа седмично. Съответствие с политиката на или над 95%.

Бизнес изисквания vs функционални изисквания vs технически изисквания

Най-честият източник на объркване по тази тема и причината много BRD всъщност да са спецификации с грешното заглавие.

Тестът: ако изискване споменава екран, поле, бутон или компонент на система, то се е изместило към функционална територия. Бизнес изискванията трябва да издържат на пълна промяна на решението. Ако смените доставчици и половината от вашия BRD стане невалидна, половината от него никога не е било бизнес изискване.

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

Подготвя се от бизнес анализатора или от продуктовия собственик или ръководителя на проекта, когато няма анализатор. Пише се със заинтересованите страни, а не за тях, защото BRD, създаден в изолация, се подписва без да бъде прочетен, което е по-лошо от това да няма BRD изобщо.

Подписват го хората, които могат да бъдат държани отговорни: бизнес спонсорът, този, който държи бюджета, и ръководителите на всяка функция, чиито работни процеси се променят. Добавете IT или delivery lead, като потвърдите, че изискванията са разбрани, а не просто че са постижими.

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

Как да напишете документ с бизнес изисквания

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

2. Идентифицирайте заинтересованите страни и правата за вземане на решения, преди да събирате каквото и да било. Като знаете кой може да каже „да“, предотвратявате повечето късни обръщания.

3. Документирайте текущото състояние честно, включително заобиколните решения. Там се крият истинските изисквания.

4. Събирайте изисквания чрез интервюта и наблюдение, не само чрез работилница. Работилниците изкарват наяве това, което хората казват, че им трябва. Наблюдението показва какво правят.

5. Пишете всяко изискване с прикрепени критерии за приемане, в същата сесия. Добавянето на критерии по-късно означава да ги пишете от памет.

6. Приоритизирайте с MoSCoW и задръжте линията на дела „Трябва да има“.

7. Записвайте предположенията, ограниченията и зависимостите изрично. Незаписаните предположения стават спорове.

8. Изграждайте матрицата за проследимост, докато вървите, вместо в края.

9. Разпространявайте за преглед с краен срок и посочен рецензент за всяка секция. „Имате ли коментари?“ към списък за разпространение води до мълчание.

10. Разходете заинтересованите страни през документа в сесия, преди да поискате подписи, след което фиксирайте базовата версия и управлявайте промените формално от този момент нататък.

Варианти на шаблона за документ с бизнес изисквания

Бележка за Agile версията: BRD и беклог не са в конкуренция. BRD улавя защо и от какво се нуждае бизнесът, което се променя бавно. Беклогът улавя какво се изгражда следващо, което се променя постоянно. Екипите, които изоставят BRD изцяло, обикновено губят нишката защо, и го преоткриват като аргумент.

Най-добри практики

• Пишете изисквания, които някой може да откаже. Неяснотата се чете като съгласие и води до спорове по-късно.

• По едно изискване на ред. Всичко, което съдържа „и“, вероятно са две.

• Прикачвайте критериите за приемане веднага, никога по-късно.

• Номерирайте всичко и никога не преномерирайте. Оттегляйте ID-тата вместо това.

• Записвайте източника на всяко изискване.

• Дръжте решенията извън него. В момента, в който назовете екран или поле, започвате да проектирате.

• Дефинирайте всеки двусмислен термин в речника. Думи като „претенция“, „потребител“ и „одобрено“ означават различни неща за различни отдели.

• Фиксирайте базовата версия при подписване и управлявайте промените формално след това.

• Дръжте списъка извън обхвата видим. Той предотвратява разширяване на обхвата повече от която и да е друга секция.

Чести грешки

• Изисквания, които не могат да бъдат опровергани. „Интуитивно“ и „надеждно“ не могат да бъдат тествани, затова се тълкуват по време на изграждането от този, който е най-близо.

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

• Решения, маскирани като изисквания. Ограничават дизайна, преди някой да е оценил опциите.

• Няма критерии за приемане, така че „готово“ става предмет на договаряне.

• Липсва секция „извън обхвата“. Това е най-евтината превенция срещу разширяване на обхвата.

• Написано за заинтересованите страни, вместо с тях. Подписва се без да се чете.

• Предположенията са оставени незаписани. Всяка програма ги има, а незаписаните са тези, които я разрушават.

• Никога не се актуализира след подписване. Изискванията се променят, а неиздържаната базова версия спира да бъде референцията, на която някой вярва.

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

Запишете текущото състояние, като го документирате

Отворете шаблона в Trupeer AI, приложете вашия brand kit, за да съответства BRD на останалите ви проектни документи, и редактирайте всяка секция директно. Настройката е в template guide.

Секцията „текущо състояние“ е мястото, където BRD са най-слаби, защото записването на това как нещо работи днес отнема повече време, отколкото всеки е предвидил, и винаги пропуска заобиколните решения. Запишете съществуващия процес веднъж и Trupeer AI ще генерира писмената документация за текущото състояние с автоматично заснети екрани, плюс разказана видео разходка, която можете да приложите като приложение. Доставчиците, които оферират срещу вашия BRD, разбират запис от две минути по-бързо от четири страници проза.

Запишете го. Документирайте го. Преведете го на 65+ езика за екипи за работа от разстояние. Съхранявайте го във вашата knowledge base. Trupeer it.

Често задавани въпроси

Има ли безплатен шаблон за документ с бизнес изисквания в Word?

Да. Word е основният формат, с бележки за насоки във всяка секция, които изтривате, докато пишете, плюс таблицата с изисквания и блокът за подписване, предварително подготвени. Безплатно изтегляне, без регистрация, без воден знак.

Мога ли да изтегля шаблон за документ с бизнес изисквания в Word безплатно?

Да. Всеки формат е безплатно изтегляне без нужда от акаунт. Използвайте го в колкото проекти искате.

Има ли шаблон за документ с бизнес изисквания във формат Word doc?

Да, включена е версия .doc за по-стари системи за документи и библиотеки, които не обработват .docx коректно.

Има ли безплатен шаблон за документ с бизнес изисквания в PDF?

Да. PDF е форматът с базова версия само за четене, който е това, което разпространявате след подписване, така че одобрената версия да не може да бъде редактирана по невнимание.

Има ли пример за документ с бизнес изисквания в PDF?

Да. Горният пример за система за разходи е включен като пълен PDF пример, с десет изисквания, критерии за приемане, приоритети по MoSCoW, предположения и рискове. Прочитането на завършен BRD е най-бързият начин да калибрирате колко конкретен трябва да бъде вашият.

Къде мога да изтегля шаблон за документ с изисквания в Word?

На тази страница, в Word, .doc, Google Docs, Excel и PDF. Всички са безплатни. Ако ви трябва функционалната спецификация вместо документът с бизнес изисквания, това е отделен документ и разликата е обяснена по-горе.

Какво е BRD?

Документ с бизнес изисквания. Той описва от какво се нуждае бизнесът от проект и защо, преди да се вземат решения как да бъде изграден, и служи като артефактът, който заинтересованите страни подписват, за да потвърдят общото разбиране.

Какво трябва да включва документът с бизнес изисквания?

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

Каква е разликата между бизнес изисквания и функционални изисквания?

Бизнес изискванията описват от какво се нуждае бизнесът и защо, независимо от каквото и да е решение. Функционалните изисквания описват какво трябва да прави системата, за да ги изпълни. „Претенциите трябва да бъдат възстановени в рамките на 10 работни дни“ е бизнес изискване. „Системата маршрутизира претенциите към одобряващия, посочен в отчетната линия на HR“ е функционално. Бизнес изискването трябва да издържи на смяна на доставчици.

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

Десет до двадесет страници за средно голям проект. Малките проекти могат да се направят за пет. След тридесет, секцията с изискванията обикновено е погълнала функционалния дизайн, който принадлежи другаде.

Кой пише документа с бизнес изисквания?

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

Кой подписва BRD?

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

Колко изисквания трябва да има BRD?

Колкото са необходими за обхвата, но ако сте над около осемдесет, проверете дали функционалните детайли не са се промъкнали. Полезен индикатор е делът „Трябва да има“: над приблизително 60%, приоритизацията не е направена правилно.

Какво е матрица за проследимост?

Таблица, която свързва всяко изискване с бизнес целта, която обслужва, функционалната спецификация, която го адресира, и тестовия сценарий, който го проверява. Тя улавя изисквания, които никога няма да бъдат тествани, и работа, която се изгражда без да се проследява към никакво изискване.

Мога ли да персонализирам този шаблон за документ с бизнес изисквания?

Да, всяка версия е напълно редактируема. Изтрийте секциите, които не се прилагат, вместо да оставяте празни заглавия, и адаптирайте таблицата с изисквания към вашата собствена схема за приоритети, ако не използвате MoSCoW. В Trupeer AI можете също да приложите вашия brand kit, така че BRD да съответства на останалата ви проектна документация.

Свързани шаблони

• Шаблон за план на проекта

• Шаблон за план за управление на проекта

• Шаблон за проектна документация

• Шаблон за техническа документация

• Шаблон за софтуерна документация

• Шаблони за тестова документация

• Шаблон за бизнес процес

• Шаблон за план за управление на промени

• Шаблон за бизнес план