Gevinster:
- Evne til å skille funksjonelle og ikke-funksjonelle krav og skrive klare, målbare kravuttrykk med støtte av kunstig intelligens
- Evne til å bruke kunstig intelligens med strukturerte spørsmål for å trekke ut brukerhistorie, akseptkriterier og omfangsgrense fra intervjunotater
- Bli vant med å sjekke AI-genererte krav for tvetydighet, motsigelser og manglende regler og bekrefte dem med interessenter
Kravanalyse er oppgaven med å definere på en fullstendig, oversiktlig og etterprøvbar måte hva et system skal gjøre. Det er et av stadiene der MIS-spesialisten produserer mest verdi; fordi en feil her vokser eksponentielt på slutten av prosjektet. Det er to grunnleggende typer kravanalyse. Funksjonskravet beskriver jobben systemet skal gjøre: "Systemet skal sende en e-post til kunden når det bekrefter bestillingen." Ikke-funksjonelt krav beskriver hvordan systemet skal være: kvaliteter som ytelse, sikkerhet, brukervennlighet og tilgjengelighet. "Rapportskjermen skal åpnes på mindre enn 2 sekunder ved gjennomsnittlig belastning" er et ikke-funksjonelt krav.
Et godt krav har tre kjennetegn: det er tydelig (det har en enkelt tolkning), det er målbart (det har en testbar terskel), og det er sporbart (det er tydelig hvilket forretningsbehov det kommer fra). «Systemet skal være raskt» møter ingen av disse; "rask" er subjektivt, kan ikke måles, kan ikke testes. På dette stadiet er AI et kraftig hjelpemiddel for å utarbeide krav og fange opp tvetydige ordlyder; men det er kun interessenten som bestemmer hvilken forretningsregel som er reell.
Brukerhistorie og akseptkriterier
Et vanlig format i moderne kravskriving er brukerhistorien: "Som en [rolle], for [formål], vil jeg ha [funksjon]." Eksempel: «Som salgsrepresentant ønsker jeg rabattberegning fra mobilskjermen slik at jeg kan komme med raske tilbud i felt». Historien er kort og forretningsorientert; Det pålegger ikke en teknisk løsning.
Hver historie bør ha akseptkriterier: testbare betingelser som må oppfylles for at historien skal anses som "ok". Et ofte brukt mønster er "Gi/Når/Da"-mønsteret: "Gi: kunden er i VIP-segmentet. Når: bestiller over 10 000 TL. Da: systemet gir 5% rabatt." Dette mønsteret eliminerer tvetydighet fordi det tydelig forbinder tilstanden og det forventede resultatet.
Tips: Når du skriver en brukerhistorie til den kunstige intelligensen, sørg for å si "generer minst 2 akseptkriterier i formatet Gitt/Når/Da for hver historie." Når modellen tvinges til å produsere benchmarks, blir skjulte hull i kravet synlige.
Trinn for trinn: AI-assistert kravutvinning
Trinn 1 — Samle rå input. Samtalelogger, e-poster, eksisterende skjermbilder, klagelister. Jo mer reell innspill, jo mindre fabrikasjon.
Trinn 2 — Trekk ut det første settet med historier. Gi rå input til kunstig intelligens og få den til å lage utkast til brukerhistorier. Dette trinnet er ikke en fullstendig liste, men et første trinn.
Trinn 3 — Legg til akseptkriterier. Generer gitte/når/da-kriterier for hver historie. En historie som det ikke kan produseres kriterier for betyr faktisk at den ikke er tilstrekkelig definert.
Trinn 4 — Skanning etter motsetninger og hull. Spør AI "er det noen motsetninger, dupliseringer eller udefinerte situasjoner mellom disse kravene?" Spør og få det sjekket. Filtrer resultatet som et menneske.
Trinn 5 — Prioriter og bekreft. Prioriter historier med interessenter basert på forretningsverdi og haster. Prioriteringsbeslutningen tilhører forretningsenheten, ikke AI.
Ikke glem ikke-funksjonelle krav
De fleste prosjektene har vanskeligheter i feltet fordi de glemmer de ikke-funksjonelle mens de skriver funksjonskravene. En rapport kan fungere "riktig", men hvis det tar 45 sekunder å åpne, vil ingen bruke den. Tabellen nedenfor viser ofte oversett ikke-funksjonelle kravtyper og målbare skriveeksempler.
Sjanger
dårlig uttrykk
målbart uttrykk
Ytelse
"Må være rask"
"Forespørselssvar < 2 sek ved gjennomsnittlig belastning"
tilgjengelighet
"Alle skal kunne bruke det"
"WCAG 2.1 AA-kompatibel; full tastaturnavigering"
Sikkerhet
"Det skal være trygt"
"Personlige data er kryptert i hvile; tilgang er rollebasert"
tilgjengelighet
"Burde være enkelt"
"Ny bruker fullfører bestillingen i 3 trinn uten opplæring"
Tilgjengelighet/kontinuitet
"Bør ikke krasje"
"Månedlig oppetid ≥ 99,5 %"
Tre minivesker: etter tallene
Tilfelle 1 - Prisen på et umålelig behov. Skjermen, som er utviklet i en bank med krav om at «rapportskjermen skal åpnes raskt», åpnet seg på 22 sekunder under feltbelastning. Utvikleren trodde han ga ordet "rask" i miljøet sitt (2 sekunder). Hvis kravet hadde blitt skrevet som "< 3 sek ved peak time, faktisk gjennomstrømning", ville problemet blitt fanget opp i testing. Ombyggingen kostet 3 uker og målbar tilleggskostnad.
Tilfelle 2 – Gap fanget opp av akseptkriterier. Mens han skrev akseptkriteriene for historien om "systemet gjelder rabatt" i et e-handelsprosjekt, la interessenten merke til at hva som ville skje hvis rabatten kom i konflikt med kupongen og VIP-rabatten ikke ble diskutert i det hele tatt. Et enkelt gitt/når/da-spørsmål forhindret feilen med dobbel rabatt før igangsetting; Denne feilen forårsaket alvorlige inntektstap i lignende prosjekter.
Tilfelle 3 – AI-laget regel. I et HR-prosjekt la AI setningen "permisjonsforespørsel blir automatisk godkjent innen 24 timer" til kravutkastet. Ingen slik automatisk godkjenning ble diskutert i møtet; Modellen hadde laget en regel som virket «rimelig». Ved siden av hvert krav skriver eksperten "kilde: hvilket intervju/dokument?" Ved å legge til kolonnen fjernet han 4 setninger uten kilde.
Svak forespørsel / sterk forespørsel
Svak melding:
Skriv brukerhistorier for dette prosjektet.
Kraftig ledetekst:
Din rolle: Du er en MIS-forretningsanalytiker. Trekk ut brukerhistorier fra intervjunotatet nedenfor.Regler:- Format: "Som en [rolle], for [formål], vil jeg ha [funksjon]."- Skriv MINST 2 akseptkriterier for hver historie i formatet Gitt/Når/Da.- Legg til en "Kilde"-kolonne ved siden av hver historie: hvilken setning i en hvilken som helst [USIKKER]-etikett er ikke klar] montering.- Skriv målbare ikke-funksjonelle krav (ytelse, sikkerhet, tilgjengelighet) i en egen del. Intervjunotat:[tekst]
Kraftig forespørsel håndhever historieformat, akseptkriterier, kildesporbarhet og ikke-funksjonelle krav på en gang; Dette gjør det lettere å kontrollere utgangen.
Fire kopierbare maler
1) Kravavklaring:
Se gjennom kravet nedenfor. Merk hver utsagn som er vag, inkommensurabel eller åpen for mer enn én tolkning, og skriv et oppklarende spørsmål for hver. Ikke gjør opp svaret. Krav: [tekst]
2) Motsetningsskanning:
I listen over krav nedenfor, finn elementer som motsier hverandre, er repeterende eller etterlater logiske hull. Rapporter hvert funn med varenumre og en begrunnelse med én setning. Liste: [tekst]
3) Generering av akseptkriterier:
Skriv minst 4 akseptkriterier for følgende brukerhistorie i formatet gitt/når/da, inkludert grense- og unntakstilfeller. Skriv også opp eventuelle punkter som forblir uklare. Historie: [tekst]
4) Omfangsoversikt:
Lag utkast til elementene "I omfang" og "Utenfor omfang" som en tabell med to kolonner i henhold til følgende krav. Merk [BEKRÆVELSE KREVES] for ethvert element du er usikker på. Krav: [tekst]
Vanlige feil
- Å tenke løsningen er et behov. "Legg til en rullegardinmeny" er en løsning, ikke et krav. Kravet sier "brukeren må kunne velge landet fra den definerte listen"; IT-teamet designer løsningen.
- Hopp over ikke-funksjonelle. Bare å skrive ned "hva du skal gjøre" og glemme "hvordan du skal være" (hastighet, sikkerhet, tilgjengelighet) er det vanligste og dyreste smutthullet.
- Bruker umålelige adjektiver. Ord som "raskt, enkelt, trygt, brukervennlig" er ugyldige uten terskel.
- Legger ikke merke til regelen som AI har laget. Modellen kan legge til "rimelige" men ikke faktisk talte regler; Be om ressurser for alle behov.
- Overlater prioriteringen til AI. Det du skal gjøre først er en beslutning om forretningsverdi; Forretningsenheten gir dette.
Forsiktig: Den farligste setningen i kravanalyse er «alle vet dette allerede». Uuttalte forutsetninger kommer ikke inn i dokumentasjonen, kommer aldri inn i koden, og dukker opp i felten. Spør AI "hva er antatt, men ikke skrevet i dette kravet?" gjør disse skjulte forutsetningene synlige.
Oppsummert
Kravanalyse definerer hva systemet skal gjøre på en tydelig, målbar og sporbar måte. Funksjonelle krav beskriver jobben, ikke-funksjonelle krav beskriver egenskapene, og sistnevnte glemmes ofte. Brukerhistorie og Gitt/Når/Da akseptkriterier er kraftige verktøy som eliminerer usikkerhet. Kunstig intelligens akselererer produksjonen av storyboards, akseptkriterier, konfliktdeteksjon og oppklarende spørsmål betydelig; Imidlertid er riktigheten av forretningsregelen, omfanget og prioriteringsbeslutningen, og kilden til hver setning, menneskets ansvar. Ikke fullfør ethvert krav som er unsourcet og umålelig.
Søknadsoppgave
Skriv en forretningsforespørsel i ett avsnitt for et tenkt "online avtalesystem" (f.eks. "Kunder skal kunne gjøre avtaler online, ansatte skal kunne se kalendere"). (1) Opprett minst 5 brukerhistorier og 2 akseptkriterier for hver med en sterk melding fra denne forespørselen. (2) Finn minst 2 skjulte hull i kriteriene produsert av modellen (f.eks. dobbel avtale samtidig, kanselleringsregel). (3) Inkluder minst 3 ikke-funksjonelle krav i en målbar form. (4) Identifiser minst 3 elementer som "Utenfor omfang". (5) Marker en regel som modellen kan ha laget og skriv hvordan du vil bekrefte den.
sjekkliste
- [ ] Jeg skrev funksjonelle og ikke-funksjonelle krav separat.
- [ ] Alle krav er klare, målbare og testbare.
- [ ] Hver historie har gitt/når/da akseptkriterier.
- [ ] Jeg kan spore kilden (samtale/dokument) til hvert krav.
- [ ] Jeg markerte de mulige reglene som AI hadde laget og la dem for bekreftelse.
- [ ] Jeg gjorde prioriteringen sammen med forretningsenheten.