Gevinster:
- Evne til at skelne mellem funktionelle og ikke-funktionelle krav og skrive klare, målbare kravudtryk med støtte fra kunstig intelligens
- Evne til at bruge kunstig intelligens med strukturerede prompter til at udtrække brugerhistorie, acceptkriterier og omfangsgrænse fra interviewnotater
- Få for vane at tjekke AI-genererede krav for tvetydighed, modsigelse og manglende regler og bekræfte dem med interessenter
Kravanalyse er opgaven med at definere på en komplet, overskuelig og kontrollerbar måde, hvad et system skal gøre. Det er et af de stadier, hvor MIS-specialisten producerer mest værdi; fordi en fejl her vokser eksponentielt i slutningen af projektet. Der er to grundlæggende typer kravanalyse. Funktionskravet beskriver det job, systemet skal udføre: "Systemet skal e-maile kunden, når det bekræfter ordren." Ikke-funktionelle krav beskriver, hvordan systemet skal være: kvaliteter som ydeevne, sikkerhed, brugervenlighed og tilgængelighed. "Rapportskærmen bør åbne på mindre end 2 sekunder ved gennemsnitlig belastning" er et ikke-funktionelt krav.
Et godt krav har tre egenskaber: det er klart (det har en enkelt fortolkning), det er målbart (det har en testbar tærskel), og det er sporbart (det er tydeligt, hvilket forretningsbehov det kommer fra). "Systemet skal være hurtigt" opfylder ingen af disse; "hurtigt" er subjektivt, kan ikke måles, kan ikke testes. På dette stadium er kunstig intelligens en kraftfuld hjælp til at udarbejde krav og fange tvetydige formuleringer; men det er kun interessenten, der bestemmer, hvilken forretningsregel der er reel.
Brugerhistorie og acceptkriterier
Et almindeligt format i moderne kravskrivning er brugerhistorien: "Som en [rolle], til [formål], vil jeg have [funktion]." Eksempel: "Som salgsrepræsentant ønsker jeg rabatberegning fra mobilskærmen, så jeg kan lave hurtige tilbud i marken." Historien er kort og forretningsorienteret; Det pålægger ikke en teknisk løsning.
Hver historie bør have acceptkriterier: testbare betingelser, der skal være opfyldt, for at historien kan betragtes som "ok". Et ofte brugt mønster er "Given/When/Then"-mønsteret: "Givt: Kunden er i VIP-segmentet. Hvornår: bestiller over 10.000 TL. Derefter: Systemet giver 5% rabat." Dette mønster eliminerer tvetydighed, fordi det klart forbinder tilstanden og det forventede resultat.
Tip: Når du skriver en brugerhistorie til den kunstige intelligens, skal du sørge for at sige "generer mindst 2 acceptkriterier i formatet Given/When/Then for hver historie." Når modellen er tvunget til at producere benchmarks, bliver skjulte huller i kravet synlige.
Trin for trin: AI-assisteret kravudtrækning
Trin 1 — Indsaml rå input. Opkaldslogger, e-mails, eksisterende skærmbilleder, klagelister. Jo mere reelt input, jo mindre fabrikation.
Trin 2 — Udpak det første sæt historier. Giv rå input til kunstig intelligens, og få den til at producere udkast til brugerhistorier. Dette trin er ikke en komplet liste, men et første trin.
Trin 3 — Tilføj acceptkriterier. Generer Given/When/Then-kriterier for hver historie. En historie, som der ikke kan fremstilles kriterier for, betyder faktisk, at den ikke er tilstrækkeligt defineret.
Trin 4 — Scanning for modsigelser og huller. Spørg AI "er der nogen modsætninger, duplikationer eller udefinerede situationer mellem disse krav?" Spørg og få det tjekket. Filtrer resultatet som et menneske.
Trin 5 — Prioriter og bekræft. Prioriter historier med interessenter baseret på forretningsværdi og haster. Prioriteringsbeslutningen tilhører forretningsenheden, ikke AI.
Glem ikke ikke-funktionelle krav
De fleste af projekterne har vanskeligheder på området, fordi de glemmer de ikke-funktionelle, mens de skriver funktionskravene. En rapport fungerer muligvis "korrekt", men hvis det tager 45 sekunder at åbne, vil ingen bruge den. Følgende tabel viser almindeligt oversete ikke-funktionelle kravtyper og målbare skriveeksempler.
Genre
dårligt udtryk
målbart udtryk
Ydeevne
"Skal være hurtig"
"Forespørgselssvar < 2 sek ved gennemsnitlig belastning"
tilgængelighed
"Alle burde kunne bruge det"
"WCAG 2.1 AA kompatibel; fuld tastaturnavigation"
Sikkerhed
"Det burde være sikkert"
"Personlige data er krypteret i hvile; adgang er rollebaseret"
tilgængelighed
"Det burde være nemt"
"Ny bruger fuldfører ordren i 3 trin uden træning"
Tilgængelighed/kontinuitet
"Bør ikke gå ned"
"Månedlig oppetid ≥ 99,5 %"
Tre minietuier: Efter numrene
Case 1 — Prisen for et umåleligt behov. Skærmen, der er udviklet i en bank med krav om, at "rapportskærmen skal åbne hurtigt", åbnede på 22 sekunder under feltbelastning. Udvikleren troede, at han gav ordet "hurtigt" i sit miljø (2 sekunder). Hvis kravet var blevet skrevet som "< 3 sek ved spidsbelastningstid, faktisk gennemløb", ville problemet være blevet fanget i test. Ombygningen kostede 3 uger og målbare meromkostninger.
Case 2 — Gab fanget af acceptkriterier. Mens han skrev acceptkriterierne for historien om "systemet anvender rabat" i et e-handelsprojekt, bemærkede interessenten, at der slet ikke blev diskuteret, hvad der ville ske, hvis rabatten var i konflikt med kuponen og VIP-rabatten. Et enkelt Given/When/Then-spørgsmål forhindrede dobbeltrabatfejlen før start; Denne fejl forårsagede alvorlige indtægtstab i lignende projekter.
Case 3 - AI-fremstillet regel. I et HR-projekt tilføjede AI sætningen "orlovsanmodning godkendes automatisk inden for 24 timer" til kravudkastet. En sådan automatisk godkendelse blev ikke drøftet på mødet; Modellen havde lavet en regel, der virkede "rimelig". Ud for hvert krav skriver eksperten "kilde: hvilket interview/dokument?" Ved at tilføje kolonnen fjernede han 4 ikke-sourcede sætninger.
Svag prompt / stærk prompt
Svag prompt:
Skriv brugerhistorier til dette projekt.
Kraftig prompt:
Din rolle: Du er en MIS-forretningsanalytiker. Udtræk brugerhistorier fra interviewnotatet nedenfor.Regler:- Format: "Som [rolle], til [formål], vil jeg have [funktion]."- Skriv MINDST 2 acceptkriterier for hver historie i formatet Givet/When/Then.- Tilføj en "Kilde"-kolonne ved siden af hver historie: hvilken sætning i nogen [USIKKER] er det ikke tydeligt, at reglen ikke er klar? montering.- Skriv målbare ikke-funktionelle krav (ydelse, sikkerhed, tilgængelighed) i et separat afsnit. Interviewnote:[tekst]
Kraftig prompt håndhæver historieformat, acceptkriterier, kildesporbarhed og ikke-funktionelle krav på én gang; Dette gør det nemmere at styre outputtet.
Fire kopierbare skabeloner
1) Kravafklaring:
Gennemgå kravet nedenfor. Markér hvert udsagn, der er vagt, inkommensurabelt eller åbent for mere end én fortolkning, og skriv et opklarende spørgsmål til hver. Lad være med at finde på svaret. Krav: [tekst]
2) Modsigelsesscanning:
På listen over krav nedenfor skal du finde elementer, der modsiger hinanden, er gentagne eller efterlader logiske huller. Rapporter hvert fund med varenumre og en begrundelse med én sætning. Liste: [tekst]
3) Generering af acceptkriterier:
Skriv mindst 4 acceptkriterier for følgende brugerhistorie i Given/When/Then-format, inklusive grænse- og undtagelsestilfælde. Angiv også punkter, der forbliver uklare. Historie: [tekst]
4) Omfangsoversigt:
Udkast til elementerne "I omfang" og "Udenfor anvendelsesområdet" som en tabel med to kolonner i henhold til følgende krav. Mærk [BEKRÆVELSE PÅKRÆVET] for enhver vare, du er usikker på. Krav: [tekst]
Almindelige fejl
- At tænke løsningen er et behov. "Tilføj en rullemenu" er en løsning, ikke et krav. Kravet siger "brugeren skal kunne vælge landet fra den definerede liste"; IT-teamet designer løsningen.
- Springer over ikke-funktionelle. Blot at skrive "hvad man skal gøre" og glemme "hvordan man skal være" (hastighed, sikkerhed, tilgængelighed) er det mest almindelige og dyreste smuthul.
- Bruger umådelige adjektiver. Ord som "hurtigt, nemt, sikkert, brugervenligt" er ugyldige uden en tærskel.
- Læg ikke mærke til reglen, som AI har lavet. Modellen kan tilføje "rimelige", men ikke faktisk talte regler; Bed om ressourcer til ethvert behov.
- Overlader prioriteringen til AI. Hvad man skal gøre først, er en forretningsværdibeslutning; Forretningsenheden giver dette.
Forsigtig: Den farligste sætning i kravanalyse er "det ved alle allerede". Uudtalte antagelser kommer ikke ind i dokumentationen, kommer aldrig ind i koden og dukker op i felten. Spørg AI "hvad er antaget, men ikke skrevet i dette krav?" gør disse skjulte antagelser synlige.
Sammenfattende
Kravanalyse definerer, hvad systemet skal gøre på en klar, målbar og sporbar måde. Funktionelle krav beskriver jobbet, ikke-funktionelle krav beskriver kvaliteterne, og sidstnævnte glemmes ofte. Brugerhistorie og Givet/When/Then acceptkriterier er kraftfulde værktøjer, der eliminerer usikkerhed. Kunstig intelligens accelererer produktionen af storyboards, acceptkriterier, konfliktdetektion og afklarende spørgsmål markant; Men rigtigheden af forretningsreglen, omfanget og prioriteringsbeslutningen og kilden til hver sætning er menneskets ansvar. Udfør ikke ethvert krav, der er usourcede og umådelige.
Ansøgningsopgave
Skriv en virksomhedsanmodning i ét afsnit om et imaginært "online aftalesystem" (f.eks. "Kunder skal kunne lave aftaler online, personale skal kunne se kalendere"). (1) Opret mindst 5 brugerhistorier og 2 acceptkriterier for hver med en stærk prompt fra denne anmodning. (2) Find mindst 2 skjulte huller i kriterierne produceret af modellen (f.eks. dobbeltaftale på samme tid, annulleringsregel). (3) Inkluder mindst 3 ikke-funktionelle krav i en målbar form. (4) Identificer mindst 3 elementer som "Udenfor anvendelsesområdet". (5) Marker en regel, som modellen kan have lavet, og skriv, hvordan du vil bekræfte den.
tjekliste
- [ ] Jeg skrev funktionelle og ikke-funktionelle krav separat.
- [ ] Alle krav er klare, målbare og testbare.
- [ ] Hver historie har Givet/Hvornår/Så acceptkriterier.
- [ ] Jeg kan spore kilden (samtale/dokument) til hvert krav.
- [ ] Jeg markerede de mulige regler, som AI'en havde opfundet, og forlod dem til bekræftelse.
- [ ] Jeg lavede prioriteringen sammen med forretningsenheden.