Vinster:
- Förmåga att särskilja funktionella och icke-funktionella krav och skriva tydliga, mätbara kravuttryck med stöd av artificiell intelligens
- Förmåga att använda artificiell intelligens med strukturerade uppmaningar för att extrahera användarberättelse, acceptanskriterier och omfattningsgräns från intervjuanteckningar
- Ta för vana att kontrollera AI-genererade krav för tvetydighet, motsägelse och saknade regler och bekräfta dem med intressenter
Kravanalys är uppgiften att på ett fullständigt, tydligt och verifierbart sätt definiera vad ett system ska göra. Det är ett av de steg där MIS-specialisten producerar mest värde; eftersom ett misstag här växer exponentiellt i slutet av projektet. Det finns två grundläggande typer av kravanalys. Funktionskravet beskriver jobbet som systemet ska göra: "Systemet ska maila kunden när det bekräftar beställningen." Icke-funktionella krav beskriver hur systemet ska vara: egenskaper som prestanda, säkerhet, användbarhet och tillgänglighet. "Rapportskärmen bör öppnas på mindre än 2 sekunder vid genomsnittlig belastning" är ett icke-funktionellt krav.
Ett bra krav har tre egenskaper: det är tydligt (det har en enda tolkning), det är mätbart (det har ett testbart tröskelvärde) och det är spårbart (det är tydligt vilket affärsbehov det kommer ifrån). "Systemet måste vara snabbt" möter ingen av dessa; "snabb" är subjektivt, kan inte mätas, kan inte testas. I detta skede är AI ett kraftfullt hjälpmedel för att formulera krav och fånga tvetydiga formuleringar; men det är bara intressenten som avgör vilken affärsregel som är verklig.
Användarberättelse och acceptanskriterier
Ett vanligt format i modern kravskrivning är användarberättelsen: "Som en [roll], för [ändamål], vill jag ha [funktion]." Exempel: "Som säljare vill jag ha rabattberäkning från mobilskärmen så att jag kan göra snabba offerter i fält." Berättelsen är kort och affärsorienterad; Det kräver ingen teknisk lösning.
Varje berättelse bör ha acceptanskriterier: testbara villkor som måste uppfyllas för att berättelsen ska anses vara "ok". Ett ofta använt mönster är "Given/When/Then"-mönstret: "Given: kunden är i VIP-segmentet. När: beställningar över 10 000 TL. Då: systemet tillämpar 5% rabatt." Detta mönster eliminerar tvetydighet eftersom det tydligt kopplar tillståndet och det förväntade resultatet.
Tips: När du skriver en användarberättelse till den artificiella intelligensen, se till att säga "generera minst 2 acceptanskriterier i formatet Given/When/Then för varje berättelse." När modellen tvingas ta fram benchmarks blir dolda luckor i kravet synliga.
Steg för steg: AI-assisterad kravextraktion
Steg 1 — Samla in rå input. Samtalsloggar, e-postmeddelanden, befintliga skärmdumpar, klagomålslistor. Ju mer verklig insats, desto mindre tillverkning.
Steg 2 — Extrahera den första uppsättningen berättelser. Ge rå input till artificiell intelligens och låt den producera utkast till användarberättelser. Detta steg är inte en komplett lista, utan ett första steg.
Steg 3 — Lägg till acceptanskriterier. Generera givna/när/då kriterier för varje berättelse. En berättelse som det inte går att ta fram kriterier för betyder faktiskt att den inte är tillräckligt definierad.
Steg 4 — Skanna efter motsägelser och luckor. Fråga AI "finns det några motsägelser, dubbletter eller odefinierade situationer mellan dessa krav?" Fråga och få det kontrollerat. Filtrera resultatet som en människa.
Steg 5 — Prioritera och bekräfta. Prioritera berättelser med intressenter baserat på affärsvärde och brådska. Prioriteringsbeslutet tillhör affärsenheten, inte AI.
Glöm inte icke-funktionella krav
De flesta av projekten har svårigheter inom området eftersom de glömmer bort de icke-funktionella när de skriver funktionskraven. En rapport kan fungera "korrekt", men om det tar 45 sekunder att öppna kommer ingen att använda den. Följande tabell visar vanliga icke-funktionella kravtyper och mätbara skrivexempel.
Genre
dåligt uttryck
mätbart uttryck
Prestanda
"Måste vara snabb"
"Frågesvar < 2 sek vid genomsnittlig belastning"
tillgänglighet
"Alla borde kunna använda det"
"WCAG 2.1 AA-kompatibel; fullständig tangentbordsnavigering"
Säkerhet
"Det ska vara säkert"
"Personliga data krypteras i vila; åtkomsten är rollbaserad"
tillgänglighet
"Borde vara lätt"
"Ny användare slutför beställningen i 3 steg utan träning"
Tillgänglighet/kontinuitet
"Borde inte krascha"
"Månatlig drifttid ≥ 99,5 %"
Tre minifodral: Efter siffrorna
Fall 1 — Priset för ett omätbart behov. Skärmen, som utvecklats i en bank med kravet att "rapportskärmen ska öppnas snabbt", öppnades på 22 sekunder under fältbelastning. Utvecklaren trodde att han gav ordet "snabb" i sin miljö (2 sekunder). Om kravet hade skrivits som "< 3 sek vid rusningstid, faktisk genomströmning", skulle problemet ha fångats i testning. Ombyggnaden kostade 3 veckor och mätbar merkostnad.
Fall 2 — Glapp fångat av acceptanskriterier. När intressenten skrev acceptanskriterierna för historien om "systemet tillämpar rabatt" i ett e-handelsprojekt märkte intressenten att vad som skulle hända om rabatten kom i konflikt med kupongen och VIP-rabatten diskuterades inte alls. En enda given/när/då-fråga förhindrade felet med dubbla rabatter innan start; Detta fel orsakade allvarliga inkomstbortfall i liknande projekt.
Fall 3 – AI-gjord regel. I ett HR-projekt lade AI till meningen "begäran om ledighet godkänns automatiskt inom 24 timmar" till kravutkastet. Inget sådant automatiskt godkännande diskuterades på mötet; Modellen hade skapat en regel som verkade "rimlig". Bredvid varje krav skriver experten "källa: vilken intervju/vilken dokument?" Genom att lägga till kolumnen tog han bort 4 meningar utan källa.
Svag prompt / Stark prompt
Svag uppmaning:
Skriv användarberättelser för detta projekt.
Kraftfull uppmaning:
Din roll: Du är en MIS-affärsanalytiker. Extrahera användarberättelser från intervjuanteckningen nedan. Regler:- Format: "Som [roll], för [syfte], vill jag ha [funktion]."- Skriv MINST 2 acceptanskriterier för varje berättelse i formatet Givet/When/Then.- Lägg till en "Källa"-kolumn bredvid varje berättelse: vilken mening i någon [OSÄKERT] är det inte tydligt? passning.- Skriv mätbara icke-funktionella krav (prestanda, säkerhet, tillgänglighet) i ett separat avsnitt. Intervjunotering:[text]
Kraftfull uppmaning tvingar fram berättelseformat, acceptanskriterier, källans spårbarhet och icke-funktionella krav på en gång; Detta gör det lättare att styra utmatningen.
Fyra kopieringsbara mallar
1) Kravförtydligande:
Granska kravet nedan. Markera varje påstående som är vagt, inkommensurabelt eller öppet för mer än en tolkning och skriv en förtydligande fråga för varje. Hitta inte på svaret. Krav: [text]
2) Motsägelseskanning:
I listan med krav nedan, hitta objekt som motsäger varandra, är repetitiva eller lämnar logiska luckor. Rapportera varje fynd med artikelnummer och en motivering med en mening. Lista: [text]
3) Generera acceptanskriterier:
Skriv minst fyra acceptanskriterier för följande användarberättelse i formatet Givet/When/Then, inklusive gräns- och undantagsfall. Lista även eventuella punkter som förblir otydliga. Berättelse: [text]
4) Omfattning:
Utforma objekten "Inom omfattning" och "Out of Scope" som en tabell med två kolumner enligt följande krav. Märk [BEKRÄFTELSE KRÄVS] för alla objekt du är osäker på. Krav: [text]
Vanliga misstag
- Att tänka lösningen är ett behov. "Lägg till en rullgardinsmeny" är en lösning, inte ett krav. Kravet säger "användaren måste kunna välja land från den definierade listan"; IT-teamet designar lösningen.
- Hoppa över icke-funktionella sådana. Att helt enkelt skriva ner "vad man ska göra" och glömma "hur man ska vara" (hastighet, säkerhet, tillgänglighet) är det vanligaste och dyraste kryphålet.
- Använder omätbara adjektiv. Ord som "snabbt, enkelt, säkert, användarvänligt" är ogiltiga utan tröskel.
- Lägger inte märke till regeln som AI har skapat. Modellen kan lägga till "rimliga" men inte faktiskt talade regler; Be om resurser för alla behov.
- Överlåter prioriteringen till AI. Vad du ska göra först är ett affärsvärdesbeslut; Affärsenheten ger detta.
Varning: Den farligaste meningen i kravanalys är "det här vet alla redan". Outtalade antaganden kommer inte in i dokumentationen, kommer aldrig in i koden och dyker upp i fältet. Fråga AI "vad antas men inte skrivits i detta krav?" gör dessa dolda antaganden synliga.
Sammanfattningsvis
Kravanalys definierar vad systemet ska göra på ett tydligt, mätbart och spårbart sätt. Funktionskrav beskriver jobbet, icke-funktionella krav beskriver egenskaperna och det senare glöms ofta bort. Användarberättelse och Givet/When/Then acceptanskriterier är kraftfulla verktyg som eliminerar osäkerhet. Artificiell intelligens påskyndar avsevärt produktionen av storyboards, acceptanskriterier, konfliktdetektering och klargörande frågor; Men riktigheten av affärsregeln, omfattning och prioriteringsbeslut och källan till varje mening är människans ansvar. Slutför inte några krav som är oinställda och omätbara.
Applikationsuppgift
Skriv en affärsförfrågan i ett stycke för ett tänkt "onlinebokningssystem" (t.ex. "Kunder ska kunna boka tid online, personal ska kunna se kalendrar"). (1) Skapa minst 5 användarberättelser och 2 acceptanskriterier för var och en med en stark uppmaning från denna begäran. (2) Hitta minst två dolda luckor i kriterierna som produceras av modellen (t.ex. dubbelbokning samtidigt, avbokningsregel). (3) Inkludera minst 3 icke-funktionella krav i en mätbar form. (4) Identifiera minst 3 objekt som "Out of Scope". (5) Markera en regel som modellen kan ha hittat på och skriv hur du skulle bekräfta den.
checklista
- [ ] Jag skrev funktionella och icke-funktionella krav separat.
- [ ] Varje krav är tydligt, mätbart och testbart.
- [ ] Varje berättelse har acceptanskriterier Givet/När/Då.
- [ ] Jag kan spåra källan (konversation/dokument) för varje krav.
- [ ] Jag markerade de möjliga reglerna som AI hade hittat på och lämnade dem för bekräftelse.
- [ ] Jag gjorde prioriteringen tillsammans med affärsenheten.