Добивки:
- Способност да разликува функционални и нефункционални барања и да пишува јасни, мерливи изрази на барања со поддршка на вештачка интелигенција
- Способност да се користи вештачка интелигенција со структурирани инструкции за да се извлече приказна за корисникот, критериумите за прифаќање и ограничувањето на опсегот од белешките за интервју
- Стекнување навика да ги проверува барањата генерирани од вештачката интелигенција за двосмисленост, контрадикторност и пропуштени правила и да ги потврди со засегнатите страни
Анализата на барањата е задача на целосен, јасен и проверлив начин да се дефинира што треба да прави системот. Тоа е една од фазите каде специјалистот за МИС произведува најголема вредност; бидејќи грешката овде експоненцијално расте на крајот на проектот. Постојат два основни типа на анализа на барањата. Функционалното барање ја опишува работата што системот треба да ја изврши: „Системот треба да му испрати е-пошта на клиентот кога ќе ја потврди нарачката“. Нефункционалното барање опишува како треба да биде системот: квалитети како што се перформанси, безбедност, употребливост и пристапност. „Екранот на извештајот треба да се отвори за помалку од 2 секунди при просечно оптоварување“ е нефункционално барање.
Доброто барање има три карактеристики: јасно е (има единствено толкување), мерливо (има праг што може да се тестира) и може да се следи (јасно е од која бизнис потреба доаѓа). „Системот мора да биде брз“ не исполнува ништо од овие; „брзото“ е субјективно, не може да се мери, не може да се тестира. Во оваа фаза, вештачката интелигенција е моќна помош во изготвувањето на барањата и фаќањето двосмислена формулација; но само засегнатата страна одлучува кое деловно правило е реално.
Корисничка приказна и критериуми за прифаќање
Вообичаен формат во пишувањето на современите барања е приказната за корисникот: „Како [улога], за [цел], сакам [функција]“. Пример: „Како претставник за продажба, сакам пресметка на попустот од екранот на мобилниот телефон за да можам да направам брзи понуди на терен“. Приказната е кратка и бизнис-ориентирана; Не наметнува техничко решение.
Секоја приказна треба да има критериуми за прифаќање: услови за тестирање кои мора да бидат исполнети за приказната да се смета за „во ред“. Често користен шаблон е шемата „Дадено/Кога/Тогаш“: „Со оглед на: клиентот е во ВИП сегментот. Кога: нарачки над 10.000 TL. Потоа: системот применува попуст од 5%. Овој модел ја елиминира двосмисленоста бидејќи јасно ги поврзува состојбата и очекуваниот исход.
Совет: Кога пишувате корисничка приказна за вештачката интелигенција, задолжително кажете „генерирај најмалку 2 критериуми за прифаќање во форматот Даден/Кога/Потоа за секоја приказна“. Кога моделот е принуден да произведува репери, скриените празнини во барањето стануваат видливи.
Чекор по чекор: Екстракција на барања со помош на вештачка интелигенција
Чекор 1 - Соберете сиров влез. Дневници на повици, е-пошта, постоечки слики од екранот, списоци со жалби. Колку повеќе реален влез, толку помалку измислици.
Чекор 2 - Извлечете го првиот сет на приказни. Дајте необработени информации за вештачката интелигенција и оставете ја да произведува нацрти на приказни од корисниците. Овој чекор не е комплетна листа, туку прв чекор.
Чекор 3 - Додадете критериуми за прифаќање. Создадете ги дадените/кога/потоа критериуми за секоја приказна. Приказна за која не може да се продуцираат критериуми всушност значи дека не е доволно дефинирана.
Чекор 4 - Скенирање за противречности и празнини. Прашајте ја вештачката интелигенција „дали има контрадикторности, дупликации или недефинирани ситуации помеѓу овие барања? Прашајте и проверете го. Филтрирајте го резултатот како човек.
Чекор 5 - Дајте приоритет и потврдете. Дајте приоритет на приказните со засегнатите страни врз основа на деловната вредност и итноста. Приоритетната одлука припаѓа на деловната единица, а не на вештачката интелигенција.
Не заборавајте за нефункционални барања
Повеќето проекти имаат потешкотии на терен бидејќи ги забораваат нефункционалните додека ги пишуваат функционалните барања. Извештајот може да работи „правилно“, но ако се потребни 45 секунди за да се отвори, никој нема да го користи. Следната табела покажува најчесто занемарени нефункционални типови барања и мерливи примери за пишување.
Жанр
лош израз
мерлив израз
Изведба
„Мора да биде брз“
„Одговор на барање < 2 секунди при просечно оптоварување“
пристапност
„Секој треба да може да го користи“
„Во согласност со WCAG 2.1 AA; целосна навигација со тастатура“
Безбедност
„Треба да биде безбедно“
„Личните податоци се шифрираат во мирување; пристапот е заснован на улоги“
достапност
„Треба да биде лесно“
„Новиот корисник ја комплетира нарачката во 3 чекори без обука“
Достапност/континуитет
„Не треба да се урне“
„Месечно време на работа ≥ 99,5%“
Три мини случаи: според бројките
Случај 1 - Цената на немерлива потреба. Екранот, кој беше развиен во банка со барање „екранот за извештај да се отвори брзо“, се отвори за 22 секунди при оптоварување на теренот. Програмерот мислеше дека го дава зборот „брзо“ во неговата околина (2 секунди). Ако барањето беше напишано како „< 3 секунди на час на врв, вистинска пропусност“, проблемот ќе беше откриен во тестирањето. Повторниот развој чинеше 3 недели и мерливи дополнителни трошоци.
Случај 2 - Јазот опфатен со критериумите за прифаќање. При пишувањето на критериумите за прифаќање за приказната „системот применува попуст“ во проект за е-трговија, засегнатата страна забележа дека воопшто не се разговарало што ќе се случи доколку попустот дојде во конфликт со купонот и ВИП попустот. Едно прашање „Дадено/Кога/Тогаш“ ја спречи грешката со двојниот попуст пред да оди во живо; Оваа грешка предизвика сериозна загуба на приходи во слични проекти.
Случај 3 - Правило направено од вештачка интелигенција. Во проект за човечки ресурси, вештачката интелигенција ја додаде реченицата „барањето за отсуство автоматски се одобрува во рок од 24 часа“ на нацртот на барањата. На состанокот не се разговарало за такво автоматско одобрување; Моделот измислил правило што изгледало „разумно“. До секое барање, експертот пишува „извор: кое интервју/документ?“ Со додавање на колоната отстрани 4 реченици без извор.
Слаба навестување / Силен навестување
Слаба навестување:
Напишете кориснички приказни за овој проект.
Моќен потсетник:
Вашата улога: Вие сте бизнис аналитичар MIS. Извадете ги корисничките приказни од белешката за интервјуто подолу. Правила:- Формат: „Како [улога], за [цел], сакам [особина].“- Напишете НАЈМАЛКУ 2 критериуми за прифаќање за секоја приказна во формат „Дадена/Кога/Потоа“. тоа не е јасно во белешката; фитинг.- Напишете мерливи нефункционални барања (перформанси, безбедност, пристапност) во посебен дел. Белешка за интервју:[текст]
Моќниот промпт го наметнува форматот на приказната, критериумите за прифаќање, следливоста на изворот и нефункционалните барања одеднаш; Ова го олеснува контролирањето на излезот.
Четири шаблони за копирање
1) Појаснување на барањата:
Прегледајте го барањето подолу. Обележете ја секоја изјава што е нејасна, неспоредлива или отворена за повеќе од едно толкување и напишете појасно прашање за секое. Не измислувајте го одговорот. Услов: [текст]
2) Скенирање на контрадикторност:
Во списокот со барања подолу, најдете ставки што се контрадикторни едни со други, се повторуваат или оставаат логички празнини. Пријавете го секој наод со броеви на ставки и оправдување од една реченица. Список: [текст]
3) Создавање критериуми за прифаќање:
Напишете најмалку 4 критериуми за прифаќање за следната корисничка приказна во формат „Дадено/Кога/Потоа“, вклучително и случаи на ограничување и исклучок. Исто така, наведете ги сите точки што остануваат нејасни. Приказна: [текст]
4) Преглед на опсегот:
Подгответе ги ставките „Во опсег“ и „Надвор од опсегот“ како табела со две колони според следните барања. Обележете [Потребна е ПОТВРДА] за која било ставка за која не сте сигурни. Барања: [текст]
Вообичаени грешки
- Размислувањето за решението е потреба. „Додај паѓачко мени“ е решение, а не услов. Условот вели „корисникот мора да може да ја избере земјата од дефинираната листа“; ИТ тимот го дизајнира решението.
- Прескокнување на нефункционалните. Едноставно запишување „што да се прави“ и заборавање „како да се биде“ (брзина, безбедност, пристапност) е најчестата и најскапата дупка.
- Користење на немерливи придавки. Зборовите како „брз, лесен, безбеден, лесен за користење“ се неважечки без праг.
- Не забележувајќи го правилото што вештачката интелигенција го има направено. Моделот може да додаде „разумни“, но всушност не изговорени правила; Побарајте ресурси за секоја потреба.
- Препуштање на приоритизацијата на вештачката интелигенција. Што да направите прво е одлука за деловна вредност; Деловната единица го дава ова.
Внимание: Најопасната реченица во анализата на барањата е „ова веќе го знаат сите“. Неискажаните претпоставки не влегуваат во документацијата, никогаш не влегуваат во кодот и се појавуваат на терен. Прашајте ја вештачката интелигенција „што се претпоставува, но не е напишано во ова барање? ги прави видливи овие скриени претпоставки.
Сумирано
Анализата на барањата дефинира што треба да направи системот на јасен, мерлив и следен начин. Функционалните барања ја опишуваат работата, нефункционалните барања ги опишуваат квалитетите, а второто често се заборава. Приказната за корисникот и критериумите за прифаќање Даден/Кога/Тогаш се моќни алатки кои ја елиминираат неизвесноста. Вештачката интелигенција значително го забрзува производството на приказни, критериуми за прифаќање, откривање конфликти и прашања за разјаснување; Сепак, исправноста на деловното правило, опсегот и приоритетната одлука и изворот на секоја реченица се одговорност на човекот. Не го финализирајте секое барање што е без извори и немерливо.
Задача за апликација
Напишете деловно барање од еден параграф за имагинарен „онлајн систем за состаноци“ (на пр., „Клиентите треба да можат да закажуваат состаноци онлајн, персоналот треба да може да гледа календари“). (1) Создадете најмалку 5 кориснички стории и 2 критериуми за прифаќање за секој со силно барање од ова барање. (2) Најдете најмалку 2 скриени празнини во критериумите произведени од моделот (на пр. двојно закажување во исто време, правило за откажување). (3) Вклучете најмалку 3 нефункционални барања во мерлива форма. (4) Идентификувајте најмалку 3 ставки како „надвор од опсегот“. (5) Означете правило што можеби го измислил моделот и напишете како би го потврдиле.
листа за проверка
- [ ] Одделно напишав функционални и нефункционални барања.
- [ ] Секое барање е јасно, мерливо и може да се тестира.
- [ ] Секоја приказна има дадени/Кога/Тогаш критериуми за прифаќање.
- [ ] Можам да го следам изворот (разговор/документ) на секое барање.
- [ ] Ги означив можните правила што вештачката интелигенција ги состави и ги оставив на потврда.
- [ ] Приоритизацијата ја направив заедно со деловната единица.