Winst:
- Vermogen om functionele en niet-functionele vereisten te onderscheiden en duidelijke, meetbare behoefteuitdrukkingen te schrijven met behulp van kunstmatige intelligentie
- Mogelijkheid om kunstmatige intelligentie te gebruiken met gestructureerde aanwijzingen om het gebruikersverhaal, de acceptatiecriteria en de reikwijdtelimiet uit interviewnotities te halen
- Er een gewoonte van maken om door AI gegenereerde vereisten te controleren op dubbelzinnigheid, tegenstrijdigheid en ontbrekende regels en deze te bevestigen met belanghebbenden
Vereistenanalyse is de taak om op een volledige, duidelijke en verifieerbare manier te definiëren wat een systeem zou moeten doen. Het is een van de fases waarin de MIS-specialist de meeste waarde creëert; omdat een fout hier aan het einde van het project exponentieel groeit. Er zijn twee basistypen van vereistenanalyse. De functionele eis beschrijft de taak die het systeem moet doen: “Het systeem moet de klant een e-mail sturen wanneer het de bestelling bevestigt.” Niet-functionele eisen beschrijven hoe het systeem zou moeten zijn: kwaliteiten zoals prestatie, veiligheid, bruikbaarheid en toegankelijkheid. "Het rapportscherm zou bij gemiddelde belasting in minder dan 2 seconden moeten openen" is een niet-functionele vereiste.
Een goede eis heeft drie kenmerken: hij is duidelijk (er is één interpretatie mogelijk), hij is meetbaar (hij heeft een toetsbare drempel) en hij is traceerbaar (het is duidelijk uit welke bedrijfsbehoefte hij voortkomt). 'Het systeem moet snel zijn' voldoet aan geen van deze eisen; “snel” is subjectief, kan niet worden gemeten, kan niet worden getest. In dit stadium is AI een krachtig hulpmiddel bij het opstellen van eisen en het opvangen van dubbelzinnige bewoordingen; maar alleen de stakeholder beslist welke bedrijfsregel reëel is.
Gebruikersverhaal en acceptatiecriteria
Een veelgebruikt formaat bij het schrijven van moderne eisen is het gebruikersverhaal: "Als [rol], voor [doel], wil ik [functie]." Voorbeeld: "Als vertegenwoordiger wil ik kortingsberekeningen vanaf het mobiele scherm, zodat ik ter plaatse snel offertes kan maken." Het verhaal is kort en zakelijk gericht; Er wordt geen technische oplossing opgelegd.
Elk verhaal moet acceptatiecriteria hebben: toetsbare voorwaarden waaraan moet worden voldaan voordat het verhaal als ‘oké’ wordt beschouwd. Een veel gebruikt patroon is het ‘Gegeven/Wanneer/Dan’-patroon: ‘Gegeven: de klant bevindt zich in het VIP-segment. Wanneer: bestelt boven de 10.000 TL. Vervolgens: het systeem past een korting van 5% toe.’ Dit patroon elimineert dubbelzinnigheid omdat het de aandoening en de verwachte uitkomst duidelijk met elkaar verbindt.
Tip: Wanneer u een gebruikersverhaal voor de kunstmatige intelligentie schrijft, zorg er dan voor dat u voor elk verhaal ten minste twee acceptatiecriteria genereert in de indeling Gegeven/Wanneer/Dan. Wanneer het model gedwongen wordt benchmarks te produceren, worden verborgen hiaten in de vereisten zichtbaar.
Stap voor stap: AI-ondersteunde extractie van vereisten
Stap 1 — Verzamel ruwe input. Oproeplogboeken, e-mails, bestaande screenshots, klachtenlijsten. Hoe meer echte input, hoe minder verzinsels.
Stap 2 — Pak de eerste reeks verhalen uit. Geef ruwe input aan kunstmatige intelligentie en laat deze concepten voor gebruikersverhalen produceren. Deze stap is geen volledige lijst, maar een eerste stap.
Stap 3 — Voeg acceptatiecriteria toe. Genereer Gegeven/Wanneer/Dan-criteria voor elk verhaal. Een verhaal waarvoor geen criteria kunnen worden opgesteld, betekent feitelijk dat het niet voldoende is gedefinieerd.
Stap 4 — Scannen op tegenstrijdigheden en hiaten. Vraag AI: “Zijn er tegenstrijdigheden, doublures of ongedefinieerde situaties tussen deze vereisten?” Vraag ernaar en laat het controleren. Filter het resultaat als mens.
Stap 5 — Prioriteer en bevestig. Geef prioriteit aan verhalen met belanghebbenden op basis van bedrijfswaarde en urgentie. De prioriteitsbeslissing behoort toe aan de business unit, niet aan de AI.
Vergeet niet-functionele vereisten niet
De meeste projecten hebben problemen in het veld omdat ze de niet-functionele problemen vergeten tijdens het schrijven van de functionele eisen. Een rapport werkt misschien ‘correct’, maar als het 45 seconden duurt om het te openen, zal niemand het gebruiken. De volgende tabel toont vaak over het hoofd geziene niet-functionele vereisten en meetbare schrijfvoorbeelden.
Genre
slechte uitdrukking
meetbare expressie
Prestaties
"Moet snel zijn"
"Queryrespons < 2 sec bij gemiddelde belasting"
toegankelijkheid
‘Iedereen zou er gebruik van moeten kunnen maken’
"WCAG 2.1 AA-compatibel; volledige toetsenbordnavigatie"
Beveiliging
‘Het moet veilig zijn’
"Persoonlijke gegevens worden in rust versleuteld; de toegang is op rollen gebaseerd"
beschikbaarheid
"Moet gemakkelijk zijn"
"Nieuwe gebruiker voltooit de bestelling in 3 stappen zonder training"
Beschikbaarheid/continuïteit
"Mag niet crashen"
"Maandelijkse uptime ≥ 99,5%"
Drie mini-hoesjes: volgens de cijfers
Geval 1 – De prijs van een onmeetbare behoefte. Het scherm, ontwikkeld in een bank met de eis dat “het meldscherm snel open moet gaan”, ging onder veldbelasting in 22 seconden open. De ontwikkelaar dacht dat hij het woord "snel" in zijn omgeving aan het verstrekken was (2 seconden). Als de vereiste was geschreven als "< 3 sec tijdens piekuur, werkelijke doorvoer", zou het probleem tijdens het testen zijn opgevangen. De herontwikkeling kostte 3 weken en meetbare meerkosten.
Geval 2 — Kloof vastgelegd door acceptatiecriteria. Tijdens het schrijven van de acceptatiecriteria voor het verhaal 'systeem past korting toe' in een e-commerceproject, merkte de stakeholder dat wat er zou gebeuren als de korting in strijd was met de coupon en de VIP-korting helemaal niet werd besproken. Eén enkele Gegeven/Wanneer/Dan-vraag voorkwam de dubbele kortingsfout vóór de livegang; Deze fout veroorzaakte een ernstig omzetverlies bij soortgelijke projecten.
Geval 3 – Door AI gemaakte regel. In een HR-project heeft AI de zin ‘verlofaanvraag wordt binnen 24 uur automatisch goedgekeurd’ toegevoegd aan het eisenconcept. Een dergelijke automatische goedkeuring werd tijdens de vergadering niet besproken; Het model had een regel bedacht die ‘redelijk’ leek. Bij elke eis schrijft de deskundige “bron: welk interview/document?” Door de kolom toe te voegen, verwijderde hij vier zinnen zonder bron.
Zwakke prompt/sterke prompt
Zwakke prompt:
Schrijf gebruikersverhalen voor dit project.
Krachtige prompt:
Jouw rol: Je bent een MIS-bedrijfsanalist. Haal gebruikersverhalen uit de onderstaande interviewnotitie. Regels: - Formaat: "Als [rol], voor [doel], wil ik [functie]." - Schrijf MINSTENS 2 acceptatiecriteria voor elk verhaal in de indeling Gegeven/Wanneer/Dan. - Voeg een kolom 'Bron' toe naast elk verhaal: uit welke zin komt het? - Label [ONZEKER] elke regel die niet duidelijk is in de notitie; passend.- Schrijf meetbare niet-functionele eisen (prestaties, beveiliging, toegankelijkheid) in een apart hoofdstuk. Interviewnotitie:[tekst]
Krachtige prompt dwingt verhaalformaat, acceptatiecriteria, traceerbaarheid van de bron en niet-functionele vereisten in één keer af; Dit maakt het eenvoudiger om de uitvoer te controleren.
Vier kopieerbare sjablonen
1) Verduidelijking van vereisten:
Bekijk de vereiste hieronder. Markeer elke bewering die vaag, incommensurabel of voor meer dan één interpretatie vatbaar is, en schrijf voor elke uitspraak een verduidelijkende vraag. Verzin het antwoord niet. Vereiste: [tekst]
2) Scannen van tegenstrijdigheden:
Zoek in de onderstaande lijst met vereisten items die elkaar tegenspreken, repetitief zijn of logische hiaten achterlaten. Rapporteer elke bevinding met itemnummers en een rechtvaardiging van één zin. Lijst: [tekst]
3) Acceptatiecriteria genereren:
Schrijf minimaal 4 acceptatiecriteria voor het volgende gebruikersverhaal in het formaat Gegeven/Wanneer/Dan, inclusief limiet- en uitzonderingsgevallen. Noteer ook eventuele punten die nog onduidelijk zijn. Verhaal: [tekst]
4) Overzicht van het toepassingsgebied:
Stel de items "Binnen bereik" en "Buiten bereik" op als een tabel met twee kolommen volgens de volgende vereisten. Label [BEVESTIGING VEREIST] voor elk item waarvan u niet zeker bent. Vereisten: [tekst]
Veel voorkomende fouten
- Denken dat de oplossing een behoefte is. "Een vervolgkeuzemenu toevoegen" is een oplossing, geen vereiste. De vereiste luidt: "de gebruiker moet het land uit de gedefinieerde lijst kunnen selecteren"; Het IT-team ontwerpt de oplossing.
- Niet-functionele overslaan. Het simpelweg opschrijven van ‘wat te doen’ en het vergeten van ‘hoe te zijn’ (snelheid, veiligheid, toegankelijkheid) is de meest voorkomende en duurste maas in de wet.
- Onmeetbare bijvoeglijke naamwoorden gebruiken. Woorden als "snel, gemakkelijk, veilig, gebruiksvriendelijk" zijn zonder drempel ongeldig.
- Het niet opmerken van de regel die de AI heeft verzonnen. Het model kan “redelijke” maar niet feitelijk gesproken regels toevoegen; Vraag om hulpmiddelen voor elke behoefte.
- Laat de prioriteitstelling over aan AI. Wat u eerst moet doen, is een beslissing over de bedrijfswaarde; De business unit geeft dit aan.
Let op: De gevaarlijkste zin in de analyse van vereisten is "iedereen weet dit al". Onuitgesproken aannames komen niet in de documentatie terecht, komen nooit in de code terecht en komen in het veld naar voren. Vraag AI: “Wat wordt er verondersteld maar niet geschreven in deze vereiste?” maakt deze verborgen aannames zichtbaar.
Samengevat
Een analyse van de vereisten definieert op een duidelijke, meetbare en traceerbare manier wat het systeem moet doen. Functionele eisen beschrijven de functie, niet-functionele eisen beschrijven de kwaliteiten, en dat laatste wordt vaak vergeten. Gebruikersverhaal en gegeven/wanneer/dan-acceptatiecriteria zijn krachtige hulpmiddelen die onzekerheid wegnemen. Kunstmatige intelligentie versnelt aanzienlijk de productie van storyboards, acceptatiecriteria, conflictdetectie en het verduidelijken van vragen; De juistheid van de bedrijfsregel, de reikwijdte en de prioriteitsbeslissing, en de bron van elke zin zijn echter de verantwoordelijkheid van de mens. Voltooi geen vereisten die niet aan bronnen zijn gekoppeld en onmeetbaar zijn.
Applicatie taak
Schrijf een zakelijk verzoek van één alinea voor een denkbeeldig ‘online afsprakensysteem’ (bijvoorbeeld: ‘Klanten moeten online afspraken kunnen maken, het personeel moet agenda’s kunnen zien’). (1) Creëer minimaal 5 gebruikersverhalen en 2 acceptatiecriteria voor elk met een sterke prompt van dit verzoek. (2) Zoek minstens twee verborgen hiaten in de criteria die door het model worden opgesteld (bijvoorbeeld dubbele afspraak tegelijkertijd, annuleringsregel). (3) Neem minimaal 3 niet-functionele eisen op in een meetbare vorm. (4) Identificeer minstens 3 items als "Buiten bereik". (5) Markeer een regel die het model mogelijk heeft bedacht en schrijf op hoe u deze zou bevestigen.
controlelijst
- [ ] Ik heb functionele en niet-functionele eisen afzonderlijk geschreven.
- [ ] Iedere eis is helder, meetbaar en toetsbaar.
- [ ] Elk verhaal heeft acceptatiecriteria Gegeven/Wanneer/Dan.
- [ ] Ik kan de bron (gesprek/document) van elke eis traceren.
- [ ] Ik markeerde de mogelijke regels die de AI had bedacht en liet ze ter bevestiging achter.
- [ ] De prioritering heb ik samen met de business unit gedaan.