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