Видове изисквания
Накратко: BABOK подрежда изискванията в четири вида: бизнес (защо), на заинтересованите страни (какво им трябва), на решението (какво прави и колко добре) и за прехода (как се стига от старото до новото). Ограниченията не са нужди, а граници.
Проблем
Всичко в един списък
След срещата със собственика бележките изглеждат така:
- Повторните поръчки да се вдигнат с 15 %.
- Клиентът да вижда старите си поръчки.
- Бутон „Поръчай пак“ до всяка поръчка.
- Страницата да се отваря бързо.
- Старите поръчки да се пренесат от сегашната система.
- Да е готово до 1 декември.
Всичко е „изискване“. Но първото се проверява след шест месеца с отчет за продажбите, третото с тест на екрана, петото веднъж и никога повече, а шестото с календар. Ако ги смесиш, няма да знаеш кое от тях кога и как да провериш.
Идеята
Какво е изискване
Изискване (requirement) е нужда, която някой има, или способност или свойство, което системата трябва да има, за да я покрие. Записано е така, че после може да се провери.
Двете части са важни. „Нужда“ значи, че зад всяко изискване стои човек и причина. „Може да се провери“ значи, че ще има момент, в който някой казва „да, изпълнено е“ или „не“.
По-точно, за любопитните
IREB CPRE дава определение в три части: изискване е (1) нужда, която заинтересована страна вижда; (2) способност или свойство, което системата трябва да има; (3) записано представяне на (1) или (2). BABOK Guide v3 го казва като използваемо представяне на нужда (a usable representation of a need). Двете казват едно и също: изискването е мостът между нечия нужда и решението.
Идеята
Четирите вида по BABOK
BABOK подрежда изискванията от „защо“ надолу до „как точно“:
| Вид | Отговаря на | В магазина |
|---|---|---|
| Бизнес изискване (business requirement) | защо правим промяната | Повторните поръчки да се вдигнат с 15 % до края на годината. |
| Изискване на заинтересована страна (stakeholder requirement) | какво трябва на една група | Клиентът да намира лесно какво е поръчал преди. |
| Изискване на решението (solution requirement), функционално | какво прави системата | Клиентът вижда предишните си поръчки и поръчва отново с един бутон. |
| Изискване на решението, нефункционално | колко добре го прави | Списъкът с поръчки се отваря за под 2 секунди при 200 поръчки. |
| Изискване за прехода (transition requirement) | как се стига от старото до новото | Поръчките от последните две години се пренасят, преди новото да тръгне. |
Функционалните и нефункционалните вече ги знаеш. Те са двете половини на изискванията на решението. Нефункционалните BABOK нарича още изисквания за качество на услугата (quality of service).
Изискванията за прехода са временни: след пускането ги няма. Затова лесно се забравят, а без тях новото тръгва без старите данни и с поддръжка, която не знае новия екран.
По-точно, за любопитните
В бележките от началото: 1 е бизнес изискване. 2 е изискване на заинтересована страна (клиента). 3 е изискване на решението, функционално, и всъщност е предложено решение за 2. 4 е нефункционално, но още без мерило: „бързо“ трябва да стане число. 5 е изискване за прехода. 6 е ограничение.
Други източници делят по друг начин. IREB CPRE има три вида: функционални изисквания, изисквания за качество (quality requirements, тоест нефункционалните) и ограничения (constraints). „Потребителско изискване“ (user requirement) е честа дума на работа. Обикновено значи изискване на заинтересованата страна, която ползва системата.
Пробвай
Кой вид е?
Идеята
Ограниченията
Някои изречения не казват какво трябва на някого, а в какво трябва да се побере решението:
- срок и бюджет: до 1 декември, за 20 000 €;
- закон: правото на връщане 14 дни от получаването, защитата на личните данни;
- договор: плащанията минават само през банката, с която има договор;
- съществуващи системи: куриерът приема адреса само в своя формат.
Това е ограничение (constraint). Обикновено не се договаря: то е било там, преди проектът да започне. Но и то се проверява, и то се забравя, затова се записва.
Идеята
Цел срещу решение
В предния урок счетоводителката поиска бутон за Excel, а нуждата беше месечният отчет. Същото се случва с всички видове изисквания.
Целта казва какво трябва да се постигне и може да се провери, без да казва как. Решението казва как. „Клиентът да разбира колко ще струва доставката преди плащането“ е цел. „Ред „Доставка“ в количката, над бутона „Плащане“, с удебелена сума“ е решение.
Решенията не са забранени. В някой момент някой трябва да реши. Опасно е, когато решението се записва вместо целта:
- целта се губи, и никой не може да провери дали решението я постига;
- изключват се по-добрите решения, без някой да ги е видял;
- тестерът проверява бутона, а не нуждата.
Проверката е проста. За всяко изискване питай „защо?“. Ако отговорът е друго изискване в списъка, значи е по-долу във веригата. Ако няма отговор, или изискването е излишно, или си пропуснал целта.
Пробвай
Цел или решение?
Упражнение
Веригата
1. От целта до екрана. Изискванията на решението служат на бизнес изискванията. Кое на кое служи и какво още трябва да се попита?
Тест