Gevinster:
- Evne til å transformere vage forretningsforespørsler til klare, testbare programvarekrav og brukerhistorier med AI-støtte
- Evne til å sammenligne fordeler og ulemper med systemdesign, datamodell og arkitektoniske beslutninger på en strukturert måte med AI
- Evne til å kritisk validere AIs foreslåtte design mot krav, skalerbarhet og begrensninger
De fleste programvareprosjekter mislykkes ikke på grunn av dårlig kode, men på grunn av misforståtte krav. En forespørsel på én setning som «La brukere laste ned rapporter» etterlater dusinvis av ubesvarte spørsmål: I hvilket format? Hvem har ansvaret? Hvor mange poster? Hva om det går sakte? Kravanalyse (oversettelse av en forretningsforespørsel til klare, testbare tekniske behov) og programvaredesign (konstruere strukturen på papir for å møte disse behovene) er stadiet der de dyreste feilene forhindres før du skriver kode. I denne enheten vil vi lære å bruke AI som en "tankepartner" på dette stadiet: en partner som avmystifiserer usikkerhet, sorterer ut alternativer, men overlater den endelige avgjørelsen til deg.
AI produserer to store verdier her. Først stiller den spørsmål du hopper over; Det bringer til overflaten skjulte antakelser og kantsaker i en forespørsel. For det andre tar den raskt opp fordeler og ulemper ved en designbeslutning. Men det er faren: AI vil gi generiske anbefalinger som "beste praksis" uten å kjenne konteksten din fullt ut (budsjett, team, eksisterende system, juridisk begrensning). Det er din jobb å filtrere dette rådet mot din egen sannhet.
Konsepter: Brukerhistorie: En kort setning som uttrykker et behov i form av "... som, jeg vil kunne... fordi...". Akseptkriterier: Testbare betingelser som må være oppfylt for at en jobb skal anses som «ferdig». Ikke-funksjonelt krav: Krav knyttet til "hvordan den vil oppføre seg" i stedet for "hva den vil gjøre", som hastighet, sikkerhet, skalerbarhet.
Fra vag forespørsel til testbart krav
Et godt krav er målbart og etterprøvbart. Ikke "la systemet være raskt", men "la søkeresultatene komme tilbake innen 500 ms". Her er en trinnvis måte å bruke AI for å begrense usikkerheten:
- Gi forespørselen som den er og få spørsmålet generert. Spør AI ikke om løsningen, men først å "liste opp noe uklart i denne forespørselen som et spørsmål."
- Du gir svarene. Bare du kjenner konteksten; Svar på AIs spørsmål med dine virkelige forretningsbegrensninger.
- Få det oversatt til brukerhistorier og akseptkriterier. Oversett det avklarte behovet til testbare elementer.
- Legg til kantsaker og negative scenarier. "Tømt resultat", "uautorisert bruker", "for stor fil" osv.
Uklarhetsutvinningsforespørsel: "Vi vil oversette følgende forretningsforespørsel til et programvarekrav. Ikke foreslå en løsning ennå. Trekk først ut ALLE uklarheter og skjulte forutsetninger som ikke er besvart i denne forespørselen som en liste med spørsmål. Grupper spørsmålene under følgende overskrifter: omfang, bruker/autoritet, datavolum, ytelse, feilhistorikk, 'Let report users' order:
Brukerhistorie + forespørsel om akseptkriterier: "Del opp følgende avklarte behov i brukerhistorier som overholder INVEST-prinsippene. Skriv 3-5 testbare akseptkriterier for hver historie (i formatet Gitt-Når-Da). Legg til minst 2 negative scenarier (uautorisert tilgang, tomme data). Behov: [skriv avklart behov her]"
Sammenligning av designbeslutninger med AI
Design er en konstant avveining: hastighet versus fleksibilitet, enkelhet versus skalerbarhet? AI setter disse avveiningene inn i et raskt regneark. For eksempel, for en "send melding"-funksjon, kan du diskutere om du skal bruke en synkron (send på forespørsel) eller asynkron (kø, send i bakgrunnen) tilnærming.
Forespørsel om designsammenligning: "Jeg designer en 'send e-postvarsling til brukeren'-funksjonen. Sammenlign de to tilnærmingene: (A) synkron levering under HTTP-forespørselen, (B) asynkron levering i bakgrunnen ved å sette den i meldingskøen. Lag en tabell på følgende akser: brukerens ventetid, feiltoleranse, kompleksitet, infrastrukturkostnadene i 2. oppsummering av en infrastruktur. velg til slutt i så fall ikke ta avgjørelsen for meg."
akse
synkron overføring
Asynkron (kø)
Brukerens ventetid
Lang (venter på forsendelse)
Kort (returnerer umiddelbart)
Feiltoleranse
Lav (forespørsel eksploderer hvis sending eksploderer)
Høy (kan prøve på nytt)
kompleksitet
lav
Middels høy (køinfrastruktur)
Infrastrukturkostnad
lav
Ekstra komponenter kreves
Hvor det passer
Lavt volum, enkel påføring
Høyt volum, kritisk levering
Tips: Å fortelle AI-en "ikke ta avgjørelsen for meg, bare vis meg alternativene og betingelsene" tvinger deg til å tenke og reduserer risikoen for blindt å akseptere et forslag. Den beste designbeslutningen er den som tas av personen som kjenner konteksten din (deg).
Svak forespørsel / sterk forespørsel
SVAK: "Design en database for ordresystemet." (Resultat: hvilken skala, hvilke relasjoner, hvilke begrensninger er ikke klare; et generelt, urealistisk opplegg.) STERKT: "Foreslå et utkast til datamodell for en liten e-handel. Entiteter: Kunde, Ordre, Produkt, Ordreelement. Begrensninger: det kan være mange produkter i en ordre; produktprisen kan endres over tid, men gjeldende pris bør bevares per 50 dagers bestilling; at "Forklar at du tok avgjørelsen. Spesifiser hvordan du løste prishistorikkproblemet. Gi det som en liste over enheter og felt, ikke kode."
Forskjellen på en kraftig ledetekst; skala (500 bestillinger per dag), forretningsregel (tidligere pris må opprettholdes) og ønsket utdataformat. En enkelt setning som "Tidligere pris må opprettholdes" endrer designet fullstendig; Hvis du ikke spesifiserer dette, vil AI produsere et unøyaktig, men plausibelt diagram.
Minivesker
Tilfelle 1 — Skjult antagelse. Et team koder direkte forespørselen "brukeren kan laste opp profilbilde". Et annet team spurte AI om usikkerhet: "maksimal størrelse? tillatte formater? upassende innholdskontroll? slette gammelt bilde?" Det produserer 8 spørsmål som. Det første teamet får vite om problemet i produksjonen når 20 MB filer fyller serveren; Det andre laget løser det i design.
Tilfelle 2 — Feil skalaantakelse. AI foreslår et komplekst cachelag for en rapporteringsfunksjon. Når ingeniøren påpeker at de virkelige dataene bare er 30 rapporter per dag, forenkler AI forslaget. Å ikke spesifisere skalaen medfører kostnadene for unødvendig kompleksitet; å spesifisere sparer 2 uker med unødvendig arbeid.
Sak 3 – Akseptkriterier gap. "Hva skjer hvis betalingen mislykkes?" Siden spørsmålet aldri ble stilt, vil et ordresystem fortsatt merke bestillingen som "bekreftet" ved mislykket betaling. Listen over negative scenarier generert av AI fanger opp dette gapet; 1 linje akseptkriterier forhindrer tap av ekte penger.
Vanlige feil
- Sender forespørselen direkte til koden. Kode skrevet før tvetydigheten er løst løser raskt feil problem.
- Tar blindt den generelle "beste praksisen" til AI. Hvis du ikke spesifiserer konteksten din (skala, budsjett, team) vil anbefalingen ikke fungere for deg.
- Hopp over ikke-funksjonelle krav. Hvis hastighet, sikkerhet og skala ikke er spesifisert, vil designet være ufullstendig.
- Tenker bare på det lykkelige scenarioet. Negative scenarier som tomme data, uautorisert bruker, feilstatus bør inkluderes i designet.
- Delegering av avgjørelsen til AI. AI genererer alternativer; Du bestemmer hvilken avveining som passer din virksomhet.
Oppsummert
Kravanalyse og design er det stadiet hvor de billigste feilene fanges opp. Her genererer AI spørsmål som avslører usikkerhet, utkast til brukerhistorier og akseptkriterier, og kartlegger designavveininger. Men bare du kjenner konteksten; Det er din jobb å filtrere AIs anbefalinger basert på skala, budsjett, team og juridiske begrensninger og ta den endelige avgjørelsen. Disiplinen «ikke ta avgjørelsen for meg, vis meg alternativene» fører til både bedre design og dypere læring.
Søknadsoppgave
Velg en jobbforespørsel på én setning fra konteksten din. Bruk først tvetydighetsprompten på AI og svar på spørsmålene med dine virkelige begrensninger. Oversett deretter det avklarte behovet til minst 2 brukerhistorier og 3 akseptkriterier for hver; Ta med minst 1 negativt scenario. Lag til slutt en sammenligningstabell for en designbeslutning (synkron/asynkron, tabellstruktur osv.) og skriv din egen beslutning i 2 setninger.
sjekkliste
- [ ] Jeg fjernet tvetydighetene som spørsmål før jeg sendte forespørselen inn i koden.
- [ ] Jeg ga konteksten (skala, autoritet, ytelse, juridisk begrensning) til AI.
- [ ] Jeg delte brukerhistoriene inn i testbare akseptkriterier.
- [ ] Jeg la til minst ett downside/edge scenario.
- [ ] Jeg evaluerte designbeslutningen med avveiningstabellen.
- [ ] Jeg tok den endelige avgjørelsen basert på konteksten min, jeg overlot det ikke til AI.