Добици:
- Способност трансформације нејасних пословних захтева у јасне, проверљиве софтверске захтеве и корисничке приче уз подршку вештачке интелигенције
- Способност упоређивања предности и мана дизајна система, модела података и архитектонских одлука на структуриран начин са АИ
- Способност критичке валидације предложеног дизајна АИ у односу на захтеве, скалабилност и ограничења
Већина софтверских пројеката пропада не због лошег кода, већ због погрешно схваћених захтева. Захтев од једне реченице попут „Дозволите корисницима да преузму извештаје“ оставља иза себе десетине неодговорених питања: У ком формату? Ко је главни? Колико записа? Шта ако је споро? Анализа захтева (превођење пословног захтева у јасне техничке потребе које се могу тестирати) и дизајн софтвера (конструисање структуре на папиру како би се задовољиле ове потребе) је фаза у којој се спречавају најскупље грешке пре писања кода. У овој јединици ћемо научити да користимо АИ као „партнера за размишљање“ у овој фази: партнера који демистификује неизвесност, разврстава опције, али коначну одлуку оставља вама.
АИ производи две велике вредности овде. Прво, поставља питања која прескочите; То извлачи на површину скривене претпоставке и рубне случајеве у захтеву. Друго, брзо приказује предности и недостатке одлуке о дизајну. Али то је опасност: АИ ће дати генеричке препоруке као „најбољу праксу“ без потпуног познавања вашег контекста (буџет, тим, постојећи систем, законска ограничења). Ваш је посао да филтрирате овај савет према сопственој истини.
Концепти: Корисничка прича: Кратка реченица која изражава потребу у облику „... као, желим да могу... зато што...“. Критеријуми прихватања: Проверљиви услови који морају бити испуњени да би се посао сматрао „урађеним“. Нефункционални захтев: Захтеви који се односе на „како ће се понашати“, а не на „шта ће радити“, као што су брзина, безбедност, скалабилност.
Од нејасног захтева до проверљивих захтева
Добар захтев је мерљив и проверљив. Не „нека систем буде брз“, већ „нека се резултати претраге врате у року од 500 мс“. Ево корак по корак начина да користите АИ за сужавање несигурности:
- Дајте захтев какав јесте и генеришите питање. Не питајте АИ за решење, већ прво да „наведе све нејасно у овом захтеву као питање“.
- Ви дајете одговоре. Само ви знате контекст; Одговорите на питања вештачке интелигенције са својим стварним пословним ограничењима.
- Нека се то преведе у корисничке приче и критеријуме прихватања. Преведите разјашњену потребу у ставке које се могу тестирати.
- Додајте рубне случајеве и негативне сценарије. „Празан резултат“, „неовлашћени корисник“, „превелика датотека“ итд.
Промпт за издвајање двосмислености: „Превешћемо следећи пословни захтев у софтверски захтев. Немојте још да предлажете решење. Прво, издвојите СВЕ нејасноће и скривене претпоставке на које није одговорено у овом захтеву као листу питања. Групишите питања под следећим насловима: обим, корисник/овлашћење, обим података, перформансе, услови грешака, историјат налога за преузимање као безбедносни захтев корисника.
Корисничка прича + упит за критеријуме прихватања: "Поделите следеће разјашњене потребе на корисничке приче које су у складу са принципима ИНВЕСТ. Напишите 3-5 критеријума прихватања који се могу тестирати за сваку причу (у формату Дато-када-Онда). Додајте најмање 2 негативна сценарија (неовлашћени приступ, празни подаци). Потреба: [овде напишите разјашњену потребу]"
Поређење дизајнерских одлука са АИ
Дизајн је стални компромис: брзина наспрам флексибилности, једноставност наспрам скалабилности? АИ ставља ове компромисе у брзу табелу. На пример, за функцију „пошаљи обавештење“ можете расправљати о томе да ли да користите синхрони (пошаљите на захтев) или асинхрони (ред, слање у позадини) приступ.
Упута за поређење дизајна: „Дизајнирам функцију 'пошаљи обавештење е-поштом кориснику'. Упоредите два приступа: (А) синхрона испорука током ХТТП захтева, (Б) асинхрона испорука у позадини тако што ћете је ставити у ред порука. Направите табелу на следећим осама: време чекања корисника, толеранција грешака, сложеност у инфраструктури, трошак отклањања грешака. на крају би изабрао у ком случају не доноси одлуку уместо мене."
осовина
синхрони пренос
Асинхрони (ред)
Време чекања корисника
Дуго (чекање на испоруку)
Кратко (одмах се враћа)
Толеранција грешака
Низак (захтев експлодира ако експлодира слање)
Висок (могућ поновни покушај)
сложеност
ниско
Средње висок (инфраструктура редова)
Трошкови инфраструктуре
ниско
Потребне су додатне компоненте
Где се уклапа
Мала запремина, једноставна примена
Велики обим, критична испорука
Савет: Ако АИ кажете „немојте да одлучујете уместо мене, само ми покажите опције и услове“ тера вас на размишљање и смањује ризик да слепо прихватите предлог. Најбоља одлука о дизајну је она коју донесе особа која познаје ваш контекст (ви).
Слаба порука / јака промпт
СЛАБО: "Дизајнирајте базу података за систем наруџби." (Резултат: која скала, који односи, која ограничења нису јасни; општа, нереална шема.) СНАЖНО: „Предложите нацрт модела података за малу е-трговину. Ентитети: купац, поруџбина, производ, ставка поруџбине. Ограничења: може бити много производа у поруџбини; цена производа може да се мења током времена, али тренутна цена треба да буде сачувана у претходном дану по поруџбини ~50; Односи и зашто то „Објасните да сте донели одлуку. Наведите како сте решили проблем историје цена. Дајте то као листу ентитета и поља, а не код."
Разлика у моћној брзини; скалу (500 поруџбина дневно), пословно правило (прошла цена мора да се задржи) и жељени излазни формат. Једна реченица као што је „Прошла цена се мора одржати“ потпуно мења дизајн; Ако ово не наведете, АИ ће произвести нетачан, али уверљив дијаграм.
Мини Цасес
Случај 1 — Скривена претпоставка. Тим директно кодира захтев „корисник може да отпреми слику профила“. Други тим је питао АИ о неизвесности: "максимална величина? дозвољени формати? неприкладна контрола садржаја? брисање старе фотографије?" Производи 8 питања попут. Први тим сазна за проблем у продукцији када 20 МБ фајлова попуни сервер; Други тим то решава у дизајну.
Случај 2 — Нетачна претпоставка размере. АИ предлаже сложен слој кеширања за функцију извештавања. Када инжењер истакне да су прави подаци само 30 извештаја дневно, АИ поједностављује предлог. Ненавођење скале доводи до трошкова непотребне сложености; навођење штеди 2 недеље непотребног рада.
Случај 3 — Недостатак критеријума прихватања. „Шта се дешава ако уплата не успе?“ Пошто питање никада није постављено, систем наруџби ће и даље означити наруџбу као „потврђену“ у случају неуспешне уплате. Листа негативних сценарија коју генерише АИ обухвата овај јаз; Критеријуми прихватања од 1 реда спречавају губитак стварног новца.
Уобичајене грешке
- Прослеђивање захтева директно коду. Код написан пре него што се нејасноћа реши брзо решава погрешан проблем.
- Слепо прихватање опште „најбоље праксе“ АИ. Ако не наведете свој контекст (размера, буџет, тим), препорука вам неће радити.
- Прескакање нефункционалних захтева. Ако брзина, сигурност и размера нису наведени, дизајн ће бити непотпун.
- Само размишљам о срећном сценарију. Негативни сценарији као што су празни подаци, неовлашћени корисник, статус грешке треба да буду укључени у дизајн.
- Делегирање одлуке на АИ. АИ генерише опције; Ви одлучујете који компромис одговара вашем пословању.
Укратко
Анализа и пројектовање захтева је фаза у којој се хватају најјефтиније грешке. Овде вештачка интелигенција генерише питања која откривају несигурност, саставља корисничке приче и критеријуме прихватања, и дијаграме дизајнира компромисе. Али само ви знате контекст; Ваш је посао да филтрирате препоруке АИ на основу вашег обима, буџета, тима и законских ограничења и донесете коначну одлуку. Дисциплина „немој да одлучујеш уместо мене, покажи ми опције“ доводи до бољег дизајна и дубљег учења.
Задатак апликације
Изаберите захтев за посао од једне реченице из свог контекста. Прво, примените упит за двосмисленост на АИ и одговорите на питања са својим стварним ограничењима. Затим преведите разјашњену потребу у најмање 2 корисничке приче и 3 критеријума прихватања за сваку; Укључите најмање 1 негативан сценарио. На крају, направите табелу поређења за одлуку о дизајну (синхрони/асинхрони, структура табеле, итд.) и напишите сопствену одлуку у 2 реченице.
контролна листа
- [ ] Уклонио сам нејасноће као питања пре него што сам проследио захтев у код.
- [ ] Дао сам контекст (размера, овлашћење, учинак, законска ограничења) АИ.
- [ ] Разбио сам корисничке приче у критеријуме прихватљивости који се могу тестирати.
- [ ] Додао сам бар један сценарио за негативну страну/ивицу.
- [ ] Проценио сам одлуку о дизајну помоћу табеле компромиса.
- [ ] Донео сам коначну одлуку на основу свог контекста, нисам то препустио АИ.