Од деловен процес до добро софтверско барање

Како разговорот за секојдневната работа да го претворите во јасен опсег, проверливи правила и прва употреблива верзија.

Тимот на Ideologix
3 мин. читање
Во оваа статија

Главната идеја

Добро барање опишува кој ја извршува задачата, со кои податоци, според кои правила и како ќе препознаеме дека е завршена правилно.

„Ни треба апликација за нарачки“ е добра почетна реченица за разговор. За да стане основа за развој, треба да разбереме како нарачката пристигнува, кој ја проверува, што ја блокира и кога се смета за завршена.

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

Следете еден вистински пример

Изберете неодамна завршена нарачка и следете ја од почеток до крај. Побарајте ги документите и пораките што ја придружувале, со отстранети чувствителни податоци. Забележете кој внесувал информации и каде истата информација се внесувала повторно.

Потоа разгледајте пример што не поминал според планот. Можеби недостигала залиха, клиентот ја сменил адресата или одобрувањето задоцнило. Исклучоците помагаат да се откријат правилата што луѓето ретко ги спомнуваат во општ опис.

Резултатот може да биде едноставна мапа: прием, проверка, одобрување, подготовка и испорака. Кај секој чекор запишете ја одговорната улога и условот за продолжување.

Раздвојте правило, екран и извештај

Екранот е начинот на кој корисникот комуницира со системот. Правилото определува што системот дозволува. Извештајот покажува што се случило. Овие работи се поврзани, но имаат различни прашања за проверка.

Барањето „додај копче за одобрување“ остава многу нејаснотии. Кој смее да го користи? Дали може да се одобри нецелосна нарачка? Дали одобрена нарачка може повторно да се менува? Што гледа магацинот по промената?

Одговорите стануваат дел од опсегот. Некогаш ќе откријат дека прво треба да се договори самиот деловен процес.

Напишете проверливи сценарија

Наместо „системот треба да биде лесен“, опишете задача што може да се демонстрира. На пример:

  • Вработен во продажба внесува нарачка со клиент и најмалку една ставка.
  • Нарачка без адреса за испорака останува во подготовка.
  • Само овластена улога може да ја одобри.
  • По одобрувањето, магацинот ја гледа во листата за подготовка.
  • Промената на статусот бележи кој ја направил и кога.

Ова не е целосна спецификација. Тоа е основа за разговор со луѓето што ќе ја користат апликацијата и за подоцнежна проверка на испорачаното.

Изберете мала, целосна прва верзија

Првиот опсег треба да заврши реална задача. Ако поддржува внес, но не и проверка или предавање на нарачката, тимот можеби и понатаму ќе мора да го води целиот процес во табела.

Изберете еден вид нарачка и ограничен број улоги. Подгответе примерни податоци и договорете кој ќе ја прифати демонстрацијата. Сложените варијанти може да следуваат откако основниот тек ќе биде проверен.

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

Прочитајте и како да одлучите меѓу готов софтвер и развој по мерка.