Gevinster:
- Evne til at omdanne vage forretningsanmodninger til klare, testbare softwarekrav og brugerhistorier med AI-understøttelse
- Evne til at sammenligne fordele og ulemper ved systemdesign, datamodel og arkitektoniske beslutninger på en struktureret måde med AI
- Evne til kritisk at validere AI's foreslåede design i forhold til krav, skalerbarhed og begrænsninger
De fleste softwareprojekter mislykkes ikke på grund af dårlig kode, men på grund af misforståede krav. En anmodning på én sætning som "Lad brugere downloade rapporter" efterlader snesevis af ubesvarede spørgsmål: I hvilket format? Hvem har ansvaret? Hvor mange poster? Hvad hvis det er langsomt? Kravanalyse (oversættelse af en forretningsanmodning til klare, testbare tekniske behov) og softwaredesign (opbygning af strukturen på papir for at imødekomme disse behov) er det stadie, hvor de dyreste fejl forhindres, før kode skrives. I denne enhed vil vi lære at bruge AI som en "tankepartner" på dette stadium: en partner, der afmystificerer usikkerhed, sorterer muligheder, men lader den endelige beslutning være op til dig.
AI producerer to store værdier her. For det første stiller den spørgsmål, du springer over; Det bringer skjulte antagelser og kantsager til overfladen i en anmodning. For det andet tabellerer den hurtigt fordele og ulemper ved en designbeslutning. Men det er faren: AI vil give generiske anbefalinger som "bedste praksis" uden fuldt ud at kende din kontekst (budget, team, eksisterende system, juridiske begrænsninger). Det er din opgave at filtrere dette råd mod din egen sandhed.
Begreber: Brugerhistorie: En kort sætning, der udtrykker et behov i form af "... som, jeg vil kunne... fordi...". Acceptkriterier: Testbare betingelser, der skal være opfyldt, for at et job kan betragtes som "udført". Ikke-funktionelt krav: Krav relateret til "hvordan det vil opføre sig" snarere end "hvad det vil gøre", såsom hastighed, sikkerhed, skalerbarhed.
Fra vag anmodning til testbart krav
Et godt krav er målbart og verificerbart. Ikke "lad systemet være hurtigt", men "lad søgeresultaterne vende tilbage inden for 500 ms". Her er en trin-for-trin måde at bruge AI til at indsnævre usikkerheden på:
- Giv anmodningen, som den er, og få spørgsmålet genereret. Spørg AI ikke om løsningen, men først om at "liste noget uklart i denne anmodning som et spørgsmål."
- Du giver svarene. Kun du kender sammenhængen; Besvar AI's spørgsmål med dine reelle forretningsmæssige begrænsninger.
- Få det omsat til brugerhistorier og acceptkriterier. Oversæt det afklarede behov til testbare elementer.
- Tilføj kantscenarier og negative scenarier. "Tømt resultat", "uautoriseret bruger", "for stor fil" osv.
Uklarhedsudtrækningsprompt: "Vi vil oversætte følgende forretningsanmodning til et softwarekrav. Foreslå ikke en løsning endnu. Udtræk først ALLE uklarheder og skjulte antagelser, som ikke er besvaret i denne anmodning, som en liste med spørgsmål. Gruppér spørgsmålene under følgende overskrifter: omfang, bruger/autoritet, datavolumen, ydeevne, fejlhistorik, '. Sikkerhedsanmodning om download af brugere'"
Brugerhistorie + acceptkriterier: "Opdel følgende afklarede behov i brugerhistorier, der overholder INVEST-principperne. Skriv 3-5 testbare acceptkriterier for hver historie (i Given-When-Then-format). Tilføj mindst 2 negative scenarier (uautoriseret adgang, tomme data). Behov: [skriv et afklaret behov her]"
Sammenligning af designbeslutninger med AI
Design er en konstant afvejning: hastighed versus fleksibilitet, enkelhed versus skalerbarhed? AI sætter disse afvejninger i et hurtigt regneark. For eksempel, for en "send notifikation"-funktion, kan du diskutere, om du vil bruge en synkron (send efter anmodning) eller asynkron (kø, send i baggrunden) tilgang.
Design-sammenligningsprompt: "Jeg er ved at designe en 'send e-mail-meddelelse til brugeren'-funktion. Sammenlign de to fremgangsmåder: (A) synkron levering under HTTP-anmodningen, (B) asynkron levering i baggrunden ved at sætte den i meddelelseskøen. Lav en tabel på følgende akser: brugerens ventetid, fejltolerance, kompleksitet, infrastrukturomkostninger i2, hvilket ville opsummere sætningen. vælg i sidste ende, i hvilket tilfælde skal du ikke træffe beslutningen for mig."
akse
synkron transmission
Asynkron (kø)
Brugerens ventetid
Lang (venter på forsendelse)
Kort (returnerer straks)
Fejltolerance
Lav (anmodningen eksploderer, hvis afsendelsen eksploderer)
Høj (forsøg muligt igen)
kompleksitet
lav
Mellem-høj (køinfrastruktur)
Infrastruktur omkostninger
lav
Yderligere komponenter påkrævet
Hvor det passer
Lav volumen, enkel applikation
Høj volumen, kritisk levering
Tip: At fortælle AI'en "tag ikke beslutningen for mig, bare vis mig mulighederne og betingelserne" tvinger dig til at tænke og reducerer risikoen for blindt at acceptere et forslag. Den bedste designbeslutning er den, der træffes af den person, der kender din kontekst (dig).
Svag prompt / stærk prompt
SWAG: "Design en database til ordresystemet." (Resultat: hvilken skala, hvilke relationer, hvilke begrænsninger er ikke klare; en generel, urealistisk ordning.) STÆRK: "Foreslå et udkast til datamodel for en lille e-handel. Enheder: Kunde, Ordre, Produkt, Ordrevare. Begrænsninger: der kan være mange produkter i en ordre; produktprisen kan ændre sig over tid, men den nuværende pris skal bevares pr. 50 dages ordre; at "Forklar, at du tog beslutningen. Angiv, hvordan du løste prishistorikproblemet. Giv det som en liste over enheder og felter, ikke kode."
Forskellen på en kraftig prompt; skala (500 ordrer pr. dag), forretningsregel (tidligere pris skal opretholdes) og det ønskede outputformat. En enkelt sætning som "Tidligere pris skal opretholdes" ændrer designet fuldstændigt; Hvis du ikke specificerer dette, vil AI’en producere et unøjagtigt, men plausibelt udseende diagram.
Mini sager
Case 1 — Skjult antagelse. Et team koder direkte anmodningen "brugeren kan uploade profilbillede". Et andet hold spurgte AI om usikkerhed: "maksimal størrelse? tilladte formater? upassende indholdskontrol? slette gammelt billede?" Det producerer 8 spørgsmål som. Det første hold lærer om problemet i produktionen, når 20 MB filer fylder serveren; Det andet hold løser det i design.
Case 2 — Forkert skalaantagelse. AI foreslår et komplekst cachelag til en rapporteringsfunktion. Når ingeniøren påpeger, at de reelle data kun er 30 rapporter om dagen, forenkler AI forslaget. At ikke specificere omfanget medfører omkostningerne ved unødvendig kompleksitet; specificering sparer 2 ugers unødvendigt arbejde.
Case 3 — Gab i acceptkriterier. "Hvad sker der, hvis betalingen mislykkes?" Da spørgsmålet aldrig blev stillet, vil et ordresystem stadig markere ordren som "bekræftet" i tilfælde af mislykket betaling. Listen over negative scenarier genereret af AI fanger dette hul; 1 linje acceptkriterier forhindrer tab af rigtige penge.
Almindelige fejl
- Sender anmodningen direkte til koden. Kode skrevet før tvetydigheden er løst løser hurtigt det forkerte problem.
- Blindt at tage den generelle "bedste praksis" af AI. Hvis du ikke angiver din kontekst (skala, budget, team), vil anbefalingen ikke fungere for dig.
- Springer ikke-funktionelle krav over. Hvis hastighed, sikkerhed og skala ikke er specificeret, vil designet være ufuldstændigt.
- Tænker bare på det lykkelige scenarie. Negative scenarier såsom tomme data, uautoriseret bruger, fejlstatus bør inkluderes i designet.
- Uddelegering af beslutningen til AI. AI genererer muligheder; Du bestemmer selv, hvilken afvejning der passer til din virksomhed.
Sammenfattende
Kravanalyse og design er det stadie, hvor de billigste fejl fanges. Her genererer AI spørgsmål, der afslører usikkerhed, udarbejder brugerhistorier og acceptkriterier og kortlægger design-afvejninger. Men kun du kender sammenhængen; Det er din opgave at filtrere AI's anbefalinger baseret på din skala, budget, team og juridiske begrænsninger og træffe den endelige beslutning. Disciplinen "tag ikke beslutningen for mig, vis mig mulighederne" fører til både bedre design og dybere læring.
Ansøgningsopgave
Vælg en jobanmodning på én sætning fra din kontekst. Anvend først tvetydighedsprompten på AI og svar på spørgsmålene med dine reelle begrænsninger. Oversæt derefter det afklarede behov til mindst 2 brugerhistorier og 3 acceptkriterier for hver; Inkluder mindst 1 negativt scenario. Lav til sidst en sammenligningstabel for en designbeslutning (synkron/asynkron, tabelstruktur osv.) og skriv din egen beslutning i 2 sætninger.
tjekliste
- [ ] Jeg fjernede uklarhederne som spørgsmål, før jeg sendte anmodningen ind i koden.
- [ ] Jeg gav konteksten (skala, autoritet, ydeevne, juridisk begrænsning) til AI.
- [ ] Jeg opdelte brugerhistorierne i testbare acceptkriterier.
- [ ] Jeg tilføjede mindst ét downside/edge scenario.
- [ ] Jeg evaluerede designbeslutningen med afvejningstabellen.
- [ ] Jeg tog den endelige beslutning baseret på min kontekst, jeg overlod det ikke til AI.