Reikalavimų analizė ir programinės įrangos projektavimas

Pelnas:

• Galimybė neaiškias verslo užklausas paversti aiškiais, išbandomais programinės įrangos reikalavimais ir naudotojų istorijomis su AI palaikymu
• Galimybė struktūriškai palyginti sistemos projektavimo, duomenų modelio ir architektūrinių sprendimų privalumus ir trūkumus su AI
• Galimybė kritiškai patvirtinti siūlomą AI dizainą, kad jis atitiktų reikalavimus, mastelį ir apribojimus

Dauguma programinės įrangos projektų žlunga ne dėl blogo kodo, o dėl nesuprastų reikalavimų. Vieno sakinio užklausa, pvz., „Leisti vartotojams atsisiųsti ataskaitas“, palieka daugybę neatsakytų klausimų: kokiu formatu? Kas vadovauja? Kiek įrašų? O jei tai lėta? Reikalavimų analizė (verslo užklausos pavertimas aiškiais, išbandytais techniniais poreikiais) ir programinės įrangos projektavimas (struktūros kūrimas popieriuje, kad atitiktų šiuos poreikius) – tai etapas, kai prieš rašant kodą išvengiama brangiausių klaidų. Šiame skyriuje išmoksime naudoti dirbtinį intelektą kaip „minčių partnerį“: partnerį, kuris išsklaido netikrumą, sprendžia galimybes, bet palieka galutinį sprendimą jums.

AI čia sukuria dvi dideles vertybes. Pirma, jis užduoda klausimus, kuriuos praleidžiate; Jis iškelia į paviršių paslėptas prielaidas ir užklausos kraštutinius atvejus. Antra, greitai pateikiami dizaino sprendimo privalumai ir trūkumai. Tačiau tai yra pavojus: AI pateiks bendras rekomendacijas kaip „geriausią praktiką“, visiškai nežinodamas jūsų konteksto (biudžeto, komandos, esamos sistemos, teisinių apribojimų). Jūsų darbas atremti šį patarimą prieš savo tiesą.

Sąvokos: Vartotojo istorija: Trumpas sakinys, išreiškiantis poreikį forma „... kaip, aš noriu galėti... nes...“. Priėmimo kriterijai: išbandomos sąlygos, kurias turi atitikti, kad darbas būtų laikomas „atliktu“. Nefunkcinis reikalavimas: reikalavimai, susiję su „kaip jis elgsis“, o ne su „ką jis veiks“, pvz., greitis, saugumas, mastelio keitimas.

Nuo neaiškaus prašymo iki tikrinamo reikalavimo

Geras reikalavimas yra išmatuojamas ir patikrinamas. Ne „tegul sistema veikia greitai“, o „tegul paieškos rezultatai grįžta per 500 ms“. Štai žingsnis po žingsnio, kaip naudoti AI siekiant sumažinti neapibrėžtumą:

1. Pateikite prašymą tokį, koks yra, ir sugeneruokite klausimą. Neklauskite dirbtinio intelekto sprendimo, o pirmiausia „įvardykite ką nors neaiškaus šiame prašyme kaip klausimą“.
2. Jūs pateikiate atsakymus. Tik jūs žinote kontekstą; Atsakykite į AI klausimus nurodydami tikruosius verslo apribojimus.
3. Leiskite tai išversti į vartotojų istorijas ir priėmimo kriterijus. Išaiškintą poreikį išverskite į tikrinamus elementus.
4. Pridėkite kraštutinių atvejų ir neigiamų scenarijų. „Tuščias rezultatas“, „neteisėtas vartotojas“, „per didelis failas“ ir kt.

Dviprasmybės ištraukimo raginimas: "Tokį verslo užklausą paversime programinės įrangos reikalavimu. Kol kas sprendimo nesiūlykite. Pirmiausia išskirkite VISUS neaiškumus ir paslėptas prielaidas, į kuriuos neatsakyta šioje užklausoje kaip klausimų sąrašą. Grupuokite klausimus pagal šias antraštes: apimtis, vartotojas / institucija, duomenų apimtis, našumas, klaidų sąlygos, sauga. Pranešti apie naudotojų užsakymą.

Naudotojo istorija + priėmimo kriterijai raginimas: "Padalinkite šį išaiškintą poreikį į naudotojų istorijas, atitinkančias INVEST principus. Kiekvienai istorijai parašykite 3–5 testuojamus priėmimo kriterijus (Formatas „Duota-Kada-tada“). Pridėkite bent 2 neigiamus scenarijus (neteisėta prieiga, tušti duomenys). Reikia: [parašyti paaiškintą poreikį čia]"

Projektavimo sprendimų palyginimas su AI

Dizainas yra nuolatinis kompromisas: greitis ir lankstumas, paprastumas prieš mastelį? AI pateikia šiuos kompromisus į greitą skaičiuoklę. Pavyzdžiui, funkcijai „siųsti pranešimą“, galite diskutuoti, ar naudoti sinchroninį (siuntimas paprašius) ar asinchroninį (eilė, siuntimas fone) metodą.

Dizaino palyginimo raginimas: "Kuriu funkciją" Siųsti pranešimą el. paštu vartotojui". Palyginkite du būdus: (A) sinchroninis pristatymas HTTP užklausos metu, (B) asinchroninis pristatymas fone, įtraukiant jį į pranešimų eilę. Sudarykite lentelę šiomis ašimis: vartotojo laukimo laikas, atsparumas gedimams, sudėtingumas, vieno sakinio sumažinimas, o tai būtų sudėtinga. galiausiai nepriimk sprendimo už mane.

ašį

sinchroninis perdavimas

Asinchroninis (eilė)

Vartotojo laukimo laikas

Ilgai (laukiu siuntos)

Trumpas (grąžina iš karto)

Gedimų tolerancija

Žemas (užklausa sprogsta, jei siuntimas sprogsta)

Aukšta (galima bandyti dar kartą)

sudėtingumo

žemas

Vidutinis aukštas (eilių infrastruktūra)

Infrastruktūros kaina

žemas

Reikalingi papildomi komponentai

Kur tinka

Mažas tūris, paprastas pritaikymas

Didelis kiekis, kritinis pristatymas

Patarimas: AI pasakymas „nepriimk sprendimo už mane, tiesiog parodyk man galimybes ir sąlygas“ verčia susimąstyti ir sumažina riziką aklai priimti pasiūlymą. Geriausias dizaino sprendimas yra tas, kurį priima asmuo, žinantis jūsų kontekstą (jūs).

Silpnas raginimas / stiprus raginimas

SILPNA: "Sukurkite duomenų bazę užsakymų sistemai." (Rezultatas: koks mastelis, kokie ryšiai, kokie apribojimai neaiškūs; bendra, nereali schema.) STIPRUS: "Siūlykite duomenų modelio juodraštį mažai el. prekybai. Subjektai: klientas, užsakymas, prekė, užsakymo elementas. Apribojimai: užsakyme gali būti daug produktų; prekės kaina laikui bėgant gali keistis, bet dabartinė užsakymo kaina turėtų būti išsaugota per 0 dienų. ir kodėl „Paaiškinkite, kad priėmėte sprendimą. Nurodykite, kaip išsprendėte kainų istorijos problemą. Pateikite jį kaip objektų ir laukų sąrašą, o ne kodą.

Galingo raginimo skirtumas; mastu (500 užsakymų per dieną), verslo taisyklę (būtina išlaikyti buvusią kainą) ir norimą išvesties formatą. Vienas sakinys, pavyzdžiui, „Būtina išlaikyti buvusią kainą“ visiškai pakeičia dizainą; Jei to nenurodysite, AI pateiks netikslią, bet patikimai atrodančią diagramą.

Mini dėklai

1 atvejis – paslėpta prielaida. Komanda tiesiogiai koduoja užklausą „vartotojas gali įkelti profilio nuotrauką“. Kita komanda paklausė AI apie netikrumą: "didžiausias dydis? Leidžiami formatai? Netinkama turinio kontrolė? Ištrinti seną nuotrauką?" Jis pateikia 8 tokius klausimus kaip. Pirmoji komanda sužino apie gamybos problemą, kai serverį užpildo 20 MB failų; Antroji komanda ją išsprendžia projektuodami.

2 atvejis – neteisinga masto prielaida. AI siūlo sudėtingą talpyklos sluoksnį ataskaitų teikimo funkcijai. Kai inžinierius nurodo, kad tikrieji duomenys yra tik 30 ataskaitų per dieną, AI supaprastina pasiūlymą. Nenurodant mastelio, patiriama bereikalingo sudėtingumo išlaidų; nurodant sutaupo 2 savaites bereikalingo darbo.

3 atvejis. Priėmimo kriterijų spraga. "Kas nutiks, jei mokėjimas nepavyks?" Kadangi klausimas niekada nebuvo užduotas, nesėkmingo mokėjimo atveju užsakymo sistema vis tiek pažymės užsakymą kaip „patvirtintą“. AI sugeneruotas neigiamų scenarijų sąrašas užfiksuoja šią spragą; 1 eilutės priėmimo kriterijai apsaugo nuo tikrų pinigų praradimo.

Dažnos klaidos

• Prašymo perdavimas tiesiai į kodą. Kodas, parašytas prieš išsprendžiant dviprasmybę, greitai išsprendžia neteisingą problemą.
• Aklai vadovaudamiesi bendra „geriausia AI praktika“. Jei nenurodysite konteksto (masto, biudžeto, komandos), rekomendacija jums netiks.
• Nefunkcinių reikalavimų praleidimas. Jei nenurodytas greitis, saugumas ir mastelis, dizainas bus neišsamus.
• Tiesiog galvoju apie laimingą scenarijų. Į dizainą turėtų būti įtraukti neigiami scenarijai, tokie kaip tušti duomenys, neteisėtas vartotojas, klaidos būsena.
• Sprendimo delegavimas AI. AI generuoja parinktis; Jūs nuspręsite, kuris kompromisas tinka jūsų verslui.

Apibendrinant

Reikalavimų analizė ir projektavimas – tai etapas, kuriame pagaunamos pigiausios klaidos. Čia dirbtinis intelektas generuoja klausimus, atskleidžiančius netikrumą, parengia vartotojų istorijas ir priėmimo kriterijus bei pateikia dizaino kompromisus. Bet tik jūs žinote kontekstą; Jūsų darbas yra filtruoti AI rekomendacijas pagal jūsų mastą, biudžetą, komandą ir teisinius apribojimus ir priimti galutinį sprendimą. Drausmė „nepriimk sprendimo už mane, parodyk man galimybes“ veda prie geresnio dizaino ir gilesnio mokymosi.

Taikymo užduotis

Iš savo konteksto pasirinkite vieno sakinio darbo užklausą. Pirma, pritaikykite dviprasmybės raginimą dirbtiniu intelektu ir atsakykite į klausimus atsižvelgdami į savo tikruosius apribojimus. Tada išverskite išaiškintą poreikį į bent 2 vartotojų istorijas ir 3 priėmimo kriterijus kiekvienam; Įtraukite bent 1 neigiamą scenarijų. Galiausiai sukurkite palyginimo lentelę dizaino sprendimui (sinchroninis / asinchroninis, lentelės struktūra ir kt.) ir parašykite savo sprendimą 2 sakiniais.

kontrolinis sąrašas

• [ ] Prieš perduodamas užklausą į kodą, pašalinau neaiškumus kaip klausimus.
• [ ] Pateikiau kontekstą (mastą, autoritetą, našumą, teisinius apribojimus) AI.
• [ ] Vartotojų istorijas suskaidžiau į testuojamus priėmimo kriterijus.
• [ ] Pridėjau bent vieną minuso / pranašumo scenarijų.
• [ ] Projektavimo sprendimą įvertinau kompromisų lentele.
• [ ] Galutinį sprendimą priėmiau remdamasis savo kontekstu, nepalikau to AI.