Vinster:
- Möjlighet att omvandla vaga affärsförfrågningar till tydliga, testbara programvarukrav och användarberättelser med AI-stöd
- Förmåga att jämföra för- och nackdelar med systemdesign, datamodell och arkitektoniska beslut på ett strukturerat sätt med AI
- Förmåga att kritiskt validera AI:s föreslagna design mot krav, skalbarhet och begränsningar
Majoriteten av mjukvaruprojekt misslyckas inte på grund av dålig kod, utan på grund av missförstådda krav. En begäran på en mening som "Låt användare ladda ner rapporter" lämnar efter sig dussintals obesvarade frågor: I vilket format? Vem är ansvarig? Hur många skivor? Tänk om det går långsamt? Kravanalys (översätta en affärsförfrågan till tydliga, testbara tekniska behov) och mjukvarudesign (konstruera strukturen på papper för att möta dessa behov) är det stadium där de dyraste misstagen förhindras innan koden skrivs. I denna enhet kommer vi att lära oss att använda AI som en "tankepartner" i detta skede: en partner som avmystifierar osäkerhet, reder ut alternativ, men lämnar det slutliga beslutet upp till dig.
AI produces two big values here. Först ställer den frågor du hoppar över; Det tar till ytan dolda antaganden och kantfall i en begäran. För det andra tar den snabbt upp för- och nackdelar med ett designbeslut. Men det är faran: AI kommer att ge generiska rekommendationer som "bästa praxis" utan att helt känna till ditt sammanhang (budget, team, befintligt system, juridiska begränsningar). Det är ditt jobb att filtrera detta råd mot din egen sanning.
Begrepp: Användarberättelse: En kort mening som uttrycker ett behov i form av "... som, jag vill kunna... för att...". Acceptanskriterier: Testbara villkor som måste uppfyllas för att ett jobb ska anses "gjort". Icke-funktionella krav: Krav relaterade till "hur det kommer att bete sig" snarare än "vad det kommer att göra", såsom hastighet, säkerhet, skalbarhet.
Från vag begäran till testbart krav
Ett bra krav är mätbart och verifierbart. Inte "låt systemet vara snabbt", utan "låt sökresultaten komma tillbaka inom 500 ms". Här är ett steg-för-steg sätt att använda AI för att minska osäkerheten:
- Ge begäran som den är och få frågan genererad. Fråga inte AI om lösningen, utan först att "lista något oklart i denna begäran som en fråga."
- Du ger svaren. Bara du känner till sammanhanget; Svara på AI:s frågor med dina verkliga affärsbegränsningar.
- Få det översatt till användarberättelser och acceptanskriterier. Översätt det klarlagda behovet till testbara objekt.
- Lägg till kantfall och negativa scenarier. "Tom resultat", "obehörig användare", "för stor fil" osv.
Obetydlighetsextraktionsprompt: "Vi kommer att översätta följande affärsbegäran till ett mjukvarukrav. Föreslå ingen lösning ännu. Extrahera först ALLA oklarheter och dolda antaganden som inte besvaras i denna begäran som en lista med frågor. Gruppera frågorna under följande rubriker: omfattning, användare/behörighet, datavolym, prestanda, felhistorik, '. Begär en rapport om användare'"
Användarberättelse + godkännandekriterier: "Dela upp följande förtydligade behov i användarberättelser som följer INVEST-principerna. Skriv 3-5 testbara godkännandekriterier för varje berättelse (i formatet Given-When-Then). Lägg till minst 2 negativa scenarier (otillåten åtkomst, tom data). Behov: [skriv förtydligat behov här]"
Jämför designbeslut med AI
Design är en konstant avvägning: hastighet kontra flexibilitet, enkelhet kontra skalbarhet? AI sätter dessa avvägningar i ett snabbt kalkylblad. Till exempel, för en "skicka meddelande"-funktion kan du diskutera om du ska använda en synkron (skicka på begäran) eller asynkron (kö, skicka i bakgrunden) tillvägagångssätt.
Uppmaning om designjämförelse: "Jag designar en funktion för att skicka e-postmeddelande till användaren. Jämför de två tillvägagångssätten: (A) synkron leverans under HTTP-förfrågan, (B) asynkron leverans i bakgrunden genom att sätta den i meddelandekön. Gör en tabell på följande axlar: användarens väntetid, feltolerans, komplexitet, infrastrukturkostnaden i2, vilket skulle innebära en sammanfattning av infrastrukturkostnaden. välj i slutändan i vilket fall Ta inte beslutet åt mig."
axel
synkron överföring
Asynkron (kö)
Användarens väntetid
Lång (väntar på leverans)
Kort (returnerar omedelbart)
Feltolerans
Låg (begäran exploderar om skicka exploderar)
Hög (försök möjligt igen)
komplexitet
låg
Medelhög (köinfrastruktur)
Infrastrukturkostnad
låg
Ytterligare komponenter krävs
Där det passar
Låg volym, enkel applikation
Hög volym, kritisk leverans
Tips: Att säga till AI:n "fattar inte beslutet åt mig, visa mig bara alternativen och villkoren" tvingar dig att tänka och minskar risken att blint acceptera ett förslag. Det bästa designbeslutet är det som tas av personen som känner till ditt sammanhang (du).
Svag prompt / Stark prompt
SVAG: "Designa en databas för ordersystemet." (Resultat: vilken skala, vilka relationer, vilka begränsningar är inte tydliga; ett allmänt, orealistiskt schema.) STARKT: "Föreslå ett utkast till datamodell för en liten e-handel. Entiteter: Kund, Order, Produkt, Orderartikel. Restriktioner: det kan finnas många produkter i en order; produktpriset kan ändras över tiden, men det aktuella priset bör bevaras per 50 dagars beställning; ~00 dagars beställning. att "Förklara att du tog beslutet. Ange hur du löste prishistorikproblemet. Ge det som en lista över enheter och fält, inte kod."
Skillnaden mellan en kraftfull uppmaning; skala (500 beställningar per dag), affärsregel (tidigare pris måste bibehållas) och önskat utdataformat. En enda mening som "Tidigare pris måste bibehållas" förändrar designen totalt; Om du inte specificerar detta kommer AI:n att producera ett felaktigt men trovärdigt diagram.
Minifodral
Fall 1 — Dolt antagande. Ett team kodar direkt begäran om "användaren kan ladda upp profilbild". Ett annat team frågade AI om osäkerhet: "maximal storlek? tillåtna format? olämplig innehållskontroll? radera gammalt foto?" Det producerar 8 frågor som. Det första laget får reda på problemet i produktionen när 20 MB filer fyller servern; Det andra laget löser det i design.
Fall 2 — Felaktigt skalantagande. AI föreslår ett komplext cachinglager för en rapporteringsfunktion. När ingenjören påpekar att den verkliga datan bara är 30 rapporter per dag, förenklar AI förslaget. Att inte specificera skalan medför kostnaden för onödig komplexitet; att specificera sparar 2 veckors onödigt arbete.
Fall 3 – Glapp i acceptanskriterierna. "Vad händer om betalningen misslyckas?" Eftersom frågan aldrig ställdes kommer ett ordersystem fortfarande att markera beställningen som "bekräftad" vid misslyckad betalning. Listan över negativa scenarier som genereras av AI fångar denna lucka; 1 rad acceptanskriterier förhindrar förlust av riktiga pengar.
Vanliga misstag
- Skickar begäran direkt till koden. Kod skriven innan tvetydigheten är löst löser snabbt fel problem.
- Att blint ta den allmänna "bästa praxis" för AI. Om du inte anger ditt sammanhang (skala, budget, team) kommer rekommendationen inte att fungera för dig.
- Hoppa över icke-funktionella krav. Om hastighet, säkerhet och skala inte specificeras kommer designen att vara ofullständig.
- Tänker bara på det lyckliga scenariot. Negativa scenarier som tom data, obehörig användare, felstatus bör inkluderas i designen.
- Delegera beslutet till AI. AI genererar alternativ; Du bestämmer vilken avvägning som passar din verksamhet.
Sammanfattningsvis
Kravanalys och design är det stadium där de billigaste felen fångas upp. Här genererar AI frågor som avslöjar osäkerhet, utkast till användarberättelser och acceptanskriterier och kartlägger designavvägningar. Men bara du känner till sammanhanget; Det är ditt jobb att filtrera AI:s rekommendationer baserat på din skala, budget, team och juridiska begränsningar och fatta det slutliga beslutet. Disciplinen "fattar inte beslutet åt mig, visa mig alternativen" leder till både bättre design och djupare lärande.
Applikationsuppgift
Välj en jobbförfrågan på en mening från ditt sammanhang. Tillämpa först tvetydighetsprompten på AI och svara på frågorna med dina verkliga begränsningar. Översätt sedan det förtydligade behovet till minst 2 användarberättelser och 3 acceptanskriterier för varje; Inkludera minst ett negativt scenario. Skapa slutligen en jämförelsetabell för ett designbeslut (synkron/asynkron, tabellstruktur etc.) och skriv ditt eget beslut i 2 meningar.
checklista
- [ ] Jag tog bort oklarheterna som frågor innan jag skickade in begäran till koden.
- [ ] Jag gav sammanhanget (skala, auktoritet, prestanda, juridiska begränsningar) till AI.
- [ ] Jag delade upp användarberättelserna i testbara acceptanskriterier.
- [ ] Jag lade till minst ett nackdel/kantscenario.
- [ ] Jag utvärderade designbeslutet med avvägningstabellen.
- [ ] Jag tog det slutliga beslutet baserat på mitt sammanhang, jag överlät det inte till AI.