Inleiding

Schrijfvereisten vormen al tientallen jaren een grote uitdaging, en een van de belangrijkste redenen hiervoor is de taal die wordt gebruikt om ze uit te drukken. Het is essentieel om vereisten op een manier te schrijven die zowel alomvattend als gemakkelijk te begrijpen is, vooral wanneer de lezers bedrijfseigenaren, eindgebruikers of belanghebbenden zijn. Dit betekent het gebruik van een "natuurlijke" taal die vrij is van technisch jargon en complexe terminologie. Natuurlijke taal is echter inherent onnauwkeurig en kan gemakkelijk verkeerd worden geïnterpreteerd of verkeerd begrepen, wat tot verdere complicaties kan leiden.

Helaas verzetten veel analisten zich tegen elke vorm van structuur in het schrijven van vereisten, en geven ze er de voorkeur aan te vertrouwen op beschrijvende paragrafen en zinnen die aanvullende vereisten kunnen impliceren. Hoewel deze aanpak misschien aantrekkelijker is voor hun lezers, leidt het vaak tot verwarring en misverstanden wanneer de vereisten worden overhandigd aan ontwikkelaars of systeemanalisten. Dit kan op zijn beurt resulteren in langdurige discussies en vertragingen bij het proberen te verduidelijken wat de vereisten eigenlijk betekenen.

Tijdens het interview met Visure Solutions, Jordanië Kyriakidis, de gewaardeerde medeoprichter en CEO van QRA Corp, deelde zijn inzichten over verschillende aspecten van requirements engineering. Tijdens dit interview hebben we een aantal behoorlijk interessante onderwerpen besproken, waaronder

• Essentiële elementen van grote vereisten
• Ezo Aaanpak voor REISEN Syntax benadering
• AI wint terrein in digitalisering van requirements engineering
• Tips en trucs voor het schrijven van geweldige vereisten
• En nog veel meer!

Wie is Jordan Kyriakidis?

Jordan Kyriakidis is een gerenommeerde leider op het gebied van ontwerp en verificatie van veiligheidskritische systemen. Hij is de mede-oprichter en CEO van QRA Corp, een bedrijf dat geavanceerde oplossingen biedt voor bedrijven en overheden om risico's te identificeren en te beperken in complexe projecten met nieuwe technologieën in gereguleerde industrieën. Met bijna twee decennia ervaring in het leiden van high-performance teams, is Jordan een ervaren wetenschapper met talloze internationale publicaties op zijn naam.

Jordan heeft een Ph.D. in Quantum Theory van de Universiteit van Basel, Zwitserland, en heeft in verschillende landen over de hele wereld gewoond en gewerkt, waaronder Europa, de Verenigde Staten en Canada. Zijn expertise op het gebied van requirements engineering, in combinatie met zijn passie om het veld vooruit te helpen, hebben hem tot een veelgevraagd spreker en opinieleider in de branche gemaakt. Jordan staat bekend om zijn visionaire benadering van het gebruik van AI en best practices voor het schrijven van vereisten in kritieke industrieën, en hij heeft een belangrijke rol gespeeld bij het digitaliseren van vereistenengineering.

Wat is Vereistenspecificatie?

Specificatie van vereisten is het proces van het duidelijk definiëren en documenteren van de functionele en niet-functionele vereisten van een systeem, softwaretoepassing of product. Het doel van de specificatie van vereisten is om de behoeften en verwachtingen van belanghebbenden, waaronder klanten, eindgebruikers en andere geïnteresseerde partijen, op een duidelijke en beknopte manier vast te leggen. Deze documentatie wordt gebruikt als blauwdruk voor het ontwerp, de ontwikkeling, het testen en de implementatie van het systeem of product. 

De specificatie van de vereisten bevat doorgaans een beschrijving van de beoogde functionaliteit, prestaties, bruikbaarheid, betrouwbaarheid, beveiliging en andere belangrijke kenmerken van het systeem of product. Het kan ook eventuele beperkingen, aannames of afhankelijkheden bevatten die van invloed kunnen zijn op het ontwerp of de implementatie van het systeem of product. De specificatie van vereisten is een essentieel onderdeel van de levenscyclus van softwareontwikkeling en dient als basis voor effectieve communicatie en samenwerking tussen belanghebbenden bij het project.

Het belang van het schrijven van geweldige vereisten

Het schrijven van goede requirements is cruciaal voor het succes van elk softwareontwikkelingsproject. Hier zijn enkele redenen waarom:

1. Duidelijke communicatie: Goed geschreven vereisten helpen ervoor te zorgen dat alle projectbetrokkenen een duidelijk en gedeeld begrip hebben van wat er wordt verwacht van het systeem of product dat wordt ontwikkeld. Deze duidelijkheid zorgt ervoor dat iedereen op dezelfde pagina zit, waardoor het risico op misverstanden en miscommunicatie wordt verkleind die kunnen leiden tot fouten, herbewerking en projectvertragingen.
2. Focus op gebruikersbehoeften: Grote vereisten richten zich op de behoeften van eindgebruikers en klanten, en zorgen ervoor dat het systeem of product dat wordt ontwikkeld, voldoet aan hun verwachtingen en vereisten. Deze aanpak verhoogt de klanttevredenheid en verkleint het risico van projectmislukking als gevolg van de mismatch tussen het product en de gebruikersbehoeften.
3. Risicomanagement: Vereisten kunnen potentiële risico's en problemen vroeg in het ontwikkelingsproces identificeren, waardoor proactieve mitigatiestrategieën kunnen worden ingevoerd. Door potentiële problemen in een vroeg stadium te identificeren, kunnen teams kostbare herbewerkingen, vertragingen en mislukkingen in de loop van de tijd voorkomen.
4. Efficiëntie: Grote vereisten helpen het ontwikkelingsproces te stroomlijnen door een duidelijk stappenplan te bieden dat ontwikkelaars kunnen volgen. Deze roadmap zorgt ervoor dat ontwikkelaars aan de belangrijkste functies en vereisten werken, waardoor verspilde moeite aan minder belangrijke taken wordt vermeden.
5. Kwaliteitsverzekering: Door goed gedefinieerde vereisten te hebben, is het gemakkelijker om ervoor te zorgen dat het systeem of product dat wordt ontwikkeld, voldoet aan de vereiste kwaliteitsnormen. Grote vereisten maken het eenvoudiger om het systeem of product dat wordt ontwikkeld te testen, te valideren en te verifiëren, zodat het op tijd, binnen het budget en met het verwachte kwaliteitsniveau wordt opgeleverd.

Kenmerken van grote vereisten

Grote vereisten zijn essentieel voor het leveren van succesvolle softwareontwikkelingsprojecten die voldoen aan de verwachtingen van de klant, op tijd worden opgeleverd en binnen het budget vallen. Hier zijn enkele kenmerken van grote vereisten:

1. Duidelijk en beknopt: Grote vereisten zijn gemakkelijk te begrijpen, met duidelijke en beknopte taal die dubbelzinnigheid of verwarring voorkomt.
2. Compleet: Grote eisen moeten alle noodzakelijke functionele en niet-functionele aspecten van het systeem of product dat wordt ontwikkeld vastleggen, zodat er geen ruimte is voor interpretatie of misverstanden.
3. nauwkeurig: Grote vereisten moeten nauwkeurig en verifieerbaar zijn, zonder discrepanties tussen wat is geschreven en wat het systeem of product geacht wordt te doen.
4. Testbaar: Grote eisen moeten testbaar zijn, wat betekent dat het mogelijk moet zijn om tests te maken die kunnen verifiëren dat het systeem of product aan de eisen voldoet.
5. geprioriteerd: Grote vereisten moeten prioriteit krijgen om ervoor te zorgen dat de belangrijkste kenmerken en functionaliteit eerst worden ontwikkeld.
6. Haalbaar: Grote eisen moeten haalbaar zijn, wat inhoudt dat ze technisch en praktisch haalbaar zijn binnen de gegeven tijd- en budgetbeperkingen.
7. traceerbaar: Grote eisen moeten traceerbaar zijn, wat betekent dat er een duidelijk verband is tussen elke eis en de bron, inclusief de belanghebbende die erom heeft gevraagd.
8. Consequent: Grote vereisten moeten consistent zijn met andere projectdocumentatie, inclusief het projectplan, de scopeverklaring en andere relevante documentatie.
9. eenduidig: Grote vereisten moeten vrij zijn van dubbelzinnigheid of verwarring, zodat er een duidelijk begrip is van wat er wordt verwacht van het systeem of product dat wordt ontwikkeld.

Uitdagingen bij het schrijven van vereisten

Er zijn verschillende uitdagingen waarmee mensen worden geconfronteerd bij het schrijven van vereisten.

Slecht papierwerk - In sommige organisaties is documentatie van processen niet aanwezig of niet in orde. In dit geval wordt het verzamelen van vereisten een proces in twee stappen: eerst het bestaande proces reverse-engineeren en vervolgens gebieden identificeren die verbetering en optimalisatie behoeven. Om te bevestigen dat vereisten uitgewerkt en nauwkeurig zijn, is het essentieel om de belangrijkste belanghebbenden en materiedeskundigen te identificeren en rechtstreeks met hen in gesprek te gaan. Het tekenen van business process maps en het visualiseren van workflows zijn twee uitstekende manieren om dit te doen. Dit helpt bij het elimineren van onjuiste aannames en geeft tegelijkertijd een compleet beeld. Het tekenen van proceskaarten en het weergeven van processen zijn hiervoor twee bruikbare benaderingen.

Tegenstrijdige eisen – Wanneer stakeholders verschillende prioriteiten hebben voor hun bedrijfsdoelen, leidt dit tot vereisten die met elkaar in strijd zijn. In dergelijke gevallen is het de verantwoordelijkheid van een bedrijfsanalist om alle vereisten in detail te documenteren, te identificeren welke verzoeken elkaar tegenspreken en belanghebbenden de kans te geven te beslissen wat prioriteit heeft.

U kunt geen beslissingen nemen zonder de input van belanghebbenden te horen, en als bedrijfsanalist heeft u misschien enkele ideeën over wat prioriteit moet krijgen. Het is nog steeds cruciaal om het perspectief van belanghebbenden te horen. Het opzetten van een peiling kan een van de methoden zijn om duidelijkheid te krijgen over wat voor de meerderheid van de belanghebbenden het belangrijkst is.

Onbeschikbaarheid van gebruikersinvoer - Een paar redenen kunnen bijdragen aan de onbeschikbaarheid van eindgebruikers en elke reden vereist zijn eigen oplossing. Soms zijn eindgebruikers bijvoorbeeld zo in beslag genomen door hun dagelijkse werk dat ze niet bereid zijn deel te nemen aan activiteiten voor het verzamelen van vereisten.

In dergelijke gevallen kan een bedrijfsanalist het beste het aantal en de duur van de opdrachten beperken. Door voorafgaand aan de bijeenkomst zoveel mogelijk onderzoek te doen, wordt de discussie overzichtelijker en informatiever. Het is bijna alsof u het verzamelen van vereisten verandert in sessies voor het valideren van vereisten. het definiëren van focusgroepen en het identificeren van de meest geschikte eindgebruikers voor elke groep

Focussen op interface in plaats van ervaring - Veel belanghebbenden en eindgebruikers hebben een duidelijk beeld van hoe de nieuwe oplossing eruit moet zien, maar ze weten niet wat het moet bereiken. De gebruikersinterface van elk systeem is cruciaal, maar mag de functionaliteit niet definiëren of verstoren.

Bedrijfsanalisten moeten er altijd aan denken om ontwerp- en functionele vereisten gescheiden te houden in hun documentatie. Door meer algemene tools zoals diagrammen, gebruikersverhalen of low-fi prototypes te gebruiken in plaats van ontwerpconcepten, kunnen ze zich blijven concentreren op de functionele aspecten van het verzamelen van vereisten.

Input van belanghebbenden – Wanneer belanghebbenden of eindgebruikers ontwerpers proberen te vertellen hoe het systeem zou moeten werken in plaats van wat het systeem zou moeten doen, kan dit leiden tot suboptimale ontwerpen. Om dit te voorkomen, valideert u elke potentiële 'onjuiste vereiste' door te vragen 'waarom?' totdat je aankomt bij het echte probleem dat moet worden opgelost.

Communicatieproblemen – Onder de problemen die kunnen leiden tot miscommunicatie tussen een business analist en andere partijen zijn taalbarrières, verkeerde aannames, onvoldoende uitgelegde woordenschat en overmatig gebruik van technische termen.

De ideale aanpak om dit probleem te voorkomen, is door regelmatig te communiceren en tweerichtingsgesprekken te voeren. Documenteer de behoeften die je hebt ontdekt en leg ze voor collegiale toetsing en kritiek voor aan verschillende vakspecialisten, maak een verklarende woordenlijst van jargon en controleer de uitgangspunten.

Veelvoorkomende fouten bij het schrijven van vereisten

Het schrijven van vereisten kan een uitdagende taak zijn en er kunnen veelgemaakte fouten worden gemaakt die van invloed kunnen zijn op het succes van het softwareontwikkelingsproject. Hier volgen enkele veelvoorkomende fouten bij het schrijven van vereisten:

1. Meerduidigheid: Een van de meest voorkomende fouten bij het schrijven van requirements is het gebruik van dubbelzinnige taal, wat kan leiden tot misverstanden en fouten. Dit kan worden voorkomen door duidelijke, beknopte en ondubbelzinnige taal te gebruiken.
2. Onvolledige of inconsistente vereisten: Vereisten die onvolledig of inconsistent zijn, kunnen leiden tot verwarring en fouten in het softwareontwikkelingsproces. Dit kan worden voorkomen door de vereisten te herzien en te valideren om er zeker van te zijn dat ze volledig en consistent zijn met andere projectdocumentatie.
3. Gebrek aan prioriteitstelling: Zonder de juiste prioritering kunnen vereisten op een lukrake manier worden ontwikkeld, wat leidt tot vertragingen en een product dat niet aan de verwachtingen van de klant voldoet. Het prioriteren van vereisten kan ervoor zorgen dat de belangrijkste functies en functionaliteit als eerste worden ontwikkeld.
4. Onduidelijke of niet-verifieerbare vereisten: Onduidelijke of niet-verifieerbare eisen kunnen leiden tot misverstanden en moeilijkheden bij het valideren dat het systeem of product aan de eisen voldoet. Dit kan worden voorkomen door ervoor te zorgen dat eisen duidelijk en controleerbaar zijn.
5. Vergulden: Gold-plating vindt plaats wanneer extra functies of functionaliteit aan het systeem of product worden toegevoegd die niet in de vereisten zijn gespecificeerd. Dit kan leiden tot vertragingen, extra kosten en een product dat niet aan de behoeften van de klant voldoet.
6. Gebrek aan betrokkenheid van belanghebbenden: Gebrek aan betrokkenheid van belanghebbenden kan leiden tot vereisten die niet voldoen aan de behoeften van klanten en andere belanghebbenden. Door belanghebbenden te betrekken bij het hele softwareontwikkelingsproces, kunnen de vereisten worden afgestemd op hun behoeften en verwachtingen.
7. Overmatige afhankelijkheid van technologie: Een te grote afhankelijkheid van technologie kan leiden tot vereisten die niet aansluiten bij de mogelijkheden van het systeem of product dat wordt ontwikkeld. Dit kan worden voorkomen door ervoor te zorgen dat de vereisten haalbaar zijn en zijn afgestemd op de gebruikte technologie.
8. Gebrek aan testoverwegingen: Testen is een belangrijk aspect van softwareontwikkeling en een gebrek aan aandacht voor testen in de vereisten kan ertoe leiden dat een product moeilijk te testen is of niet aan de kwaliteitsnormen voldoet.

Vereisten schrijven met behulp van natuurlijke taalmethoden

Het schrijven van vereisten met behulp van natuurlijke taalmethoden omvat het gebruik van alledaagse taal om de vereisten op een duidelijke, beknopte en gemakkelijk te begrijpen manier over te brengen. Deze aanpak wordt vaak gebruikt in softwareontwikkeling en andere industrieën waar behoefte bestaat aan het vastleggen en documenteren van vereisten die gemakkelijk te begrijpen zijn voor alle belanghebbenden, ongeacht hun technische expertise.

Natuurlijke taal is de taal die we gebruiken in onze dagelijkse communicatie, zoals Engels, Frans, Spaans, enzovoort. Het schrijven van vereisten in natuurlijke taal houdt in dat dezelfde taal wordt gebruikt die belanghebbenden gebruiken in hun dagelijkse communicatie, in plaats van technisch jargon of gespecialiseerde taal die onbekend is voor niet-technische belanghebbenden.

In vergelijking met andere talen voor schrijfvereisten heeft natuurlijke taal het voordeel dat het gemakkelijker te begrijpen is voor niet-technische belanghebbenden. Het gebruik van natuurlijke taal kan ervoor zorgen dat vereisten effectief worden gecommuniceerd naar alle belanghebbenden, wat leidt tot een succesvoller projectresultaat. Daarentegen zijn andere talen voor het schrijven van vereisten, zoals talen voor formele specificatie, misschien nauwkeuriger en ondubbelzinniger, maar kunnen ze moeilijker te begrijpen zijn voor niet-technische belanghebbenden.

Om requirements te schrijven met behulp van natuurlijke taalmethoden, is het belangrijk om eenvoudige, alledaagse taal te gebruiken die gemakkelijk te begrijpen is. Vereisten moeten specifiek, meetbaar en verifieerbaar zijn en mogen geen vage termen of technisch jargon gebruiken. Het gebruik van sjablonen, voorbeelden en afbeeldingen kan ook helpen om de vereisten duidelijker en beknopter te maken.

EARS-sjabloon

De EARS-sjabloon (Easy Approach to Requirements Syntax) is een sjabloon voor het verzamelen en documenteren van vereisten die een gestructureerde manier biedt om vereisten vast te leggen en te documenteren. Het wordt vaak gebruikt in sectoren zoals ruimtevaart, defensie en softwareontwikkeling, waar het nodig is om complexe en vaak technische vereisten vast te leggen en te documenteren. Het EARS-sjabloon kan worden gebruikt voor zowel functionele als niet-functionele vereisten.

Het EARS-sjabloon bestaat uit vier hoofdsecties:

1. Milieu: In dit gedeelte wordt de context beschreven waarin het systeem zal werken, inclusief eventuele beperkingen of afhankelijkheden waarmee rekening moet worden gehouden.
2. Acteur: In dit gedeelte worden de verschillende typen gebruikers of systemen beschreven die met het systeem zullen communiceren, inclusief hun rollen en verantwoordelijkheden.
3. Eis: In dit gedeelte worden de specifieke vereisten voor het systeem beschreven, inclusief zowel functionele als niet-functionele vereisten. Elke vereiste wordt op een duidelijke en beknopte manier gedefinieerd met behulp van een gestandaardiseerde syntaxis.
4. stimulans: In dit gedeelte worden de inputs beschreven die het systeem triggeren om bepaalde acties of reacties uit te voeren, en de verwachte outputs of reacties.

Om de EARS-sjabloon te gebruiken, moet de vereistenanalist of het team eerst de omgeving identificeren waarin het systeem zal werken, inclusief eventuele beperkingen of afhankelijkheden. Vervolgens moeten ze de verschillende actoren of gebruikers identificeren die interactie hebben met het systeem en hun rollen en verantwoordelijkheden. Vervolgens moeten ze de specifieke vereisten voor het systeem identificeren, met behulp van de gestandaardiseerde syntaxis die in de sjabloon is gedefinieerd. Ten slotte moeten ze de stimuli identificeren die het systeem ertoe aanzetten om bepaalde acties of reacties uit te voeren, en de verwachte resultaten of reacties.

De EARS-sjabloon is ontworpen om op een duidelijke en beknopte manier vereisten te documenteren, waardoor het gemakkelijker wordt om de vereisten te begrijpen en te verifiëren. Het wordt vaak gebruikt in industrieën waar behoefte is aan precieze en nauwkeurige vereisten, zoals ruimtevaart, defensie en softwareontwikkeling. Door het EARS-sjabloon te gebruiken, kunnen vereistenanalisten ervoor zorgen dat alle relevante vereisten op een consistente en gestructureerde manier worden vastgelegd en gedocumenteerd.

INCOSE-richtlijnen - Sjabloon

INCOSE, of de International Council on Systems Engineering, is een internationale ledenorganisatie zonder winstoogmerk die standaarden en richtlijnen biedt om organisaties te helpen betere systems engineering-processen te creëren. De INCOSE System Requirements Standard (SRS) bevat een reeks regels en standaarden die zijn ontworpen om organisaties te helpen vereistenverklaringen te evalueren voordat ze worden geïmplementeerd. De SRS is overgenomen door een aantal grote bedrijven en overheidsinstanties over de hele wereld en kan in veel verschillende industrieën voor verschillende toepassingen worden gebruikt. Het is belangrijk voor belanghebbenden zoals softwareontwikkelaars, bedrijfsanalisten, projectmanagers, testers, personeel van de IT-afdeling en andere teamleden om een ​​goed begrip te hebben van deze vereisten voordat ze aan een systeemvereistenverklaring of project beginnen te werken.

Uiteindelijk houdt het schrijven van goede eisen een zorgvuldige balans in tussen gedetailleerd en beknopt zijn, en ervoor zorgen dat de eis toetsbaar en haalbaar is. De INCOSE SRS biedt principes en richtlijnen zodat teams eisen van goede kwaliteit kunnen schrijven en ervoor kunnen zorgen dat hun projecten succesvol zijn. Dit helpt kostbare fouten tijdens de ontwikkeling of na de implementatie te voorkomen, waardoor organisaties in kortere tijd betere systemen kunnen creëren.

Wat zijn INCOSE-regels?

Eisverklaringen worden geëvalueerd volgens de regels van INCOSE. Deze normen helpen organisaties de haalbaarheid en kwaliteit van vereisten te beoordelen voordat ze worden geïmplementeerd. Het evaluatieproces omvat vier hoofdcriteria:

• Doorzichtig - De schriftelijke vereisten moeten duidelijk, gemakkelijk leesbaar en begrijpelijk zijn. Specificeer duidelijk de informatie met behulp van bevestigende zinnen die tussen de acteurs moeten worden uitgewisseld. Elke eis moet duidelijke succescriteria beschrijven. Probeer eenvoudige woordenschat te gebruiken en afkortingen te vermijden. Bijvoorbeeld: "De gebruiker kan het auditlogboekrapport bekijken".
• atoom - Elke vereiste moet worden behandeld als een afzonderlijke testcase. Voegwoorden zoals en, of, enzovoort mogen niet worden gebruikt, omdat ze kunnen leiden tot het missen van vereisten. Dit is met name cruciaal omdat termen als deze ervoor kunnen zorgen dat softwareontwikkelaars en testers vereisten over het hoofd zien. Het opsplitsen van gecompliceerde behoeften in kleinere delen totdat ze allemaal afzonderlijk kunnen worden getest, is een manier om dit te voorkomen.
• ondubbelzinnig – Onduidelijke, onvolledige of tegenstrijdige vereisten kunnen leiden tot fouten en herbewerking. Om dit te voorkomen, moeten de vereisten door elke belanghebbende worden beoordeeld voordat ze worden afgerond. Zo worden eventuele hiaten in een vroeg stadium gesignaleerd, die vervolgens kunnen worden aangepakt.
• verifieerbaar – Iedereen in het ontwikkelingsteam moet toegang hebben tot het document, zodat ze er zo vaak als nodig naar kunnen verwijzen. Omdat eisen duidelijk moeten zijn, willen teamleden niet meer informatie. Ze moeten allemaal toegankelijk zijn in het SRS-document.
• Nodig - Elke vereiste moet iets documenteren dat de gebruikers echt nodig hebben of iets dat vereist is om te voldoen aan een standaard- of integratiebehoefte vanwege het bestaan ​​van een externe interface. Het is ook belangrijk om voor elke vereiste een geautoriseerde bron te hebben.
• Ontwerponafhankelijk – Elke vereiste moet definiëren wat nodig is, niet hoe het zal worden geïmplementeerd. De vereisten moeten de kenmerken van het systeem definiëren die extern worden waargenomen, niet de interne details.
• Redelijk - Elke vereiste moet technisch uitvoerbaar zijn en moet worden geïmplementeerd rekening houdend met het budget, de deadline en andere beperkingen die van invloed zijn op het project. De vereisten moeten de werkelijke stand van zaken weerspiegelen, inclusief kosten, tijdlijn en technologie. Ze mogen niet afhankelijk zijn van toekomstige technologische ontwikkelingen.
• Compleet - Het vereistendocument moet voldoende informatie bevatten voor uw ontwikkelingsteam en testers om het product te voltooien en ervoor te zorgen dat het zonder bugs aan de vereisten van de gebruiker voldoet.
• Juist - Vereisten die in de documenten worden gespecificeerd, moeten zeer nauwkeurig zijn om elke vorm van verwarring te voorkomen. Ze mogen geen mazen, dubbelzinnigheden, subjectiviteit, superlatieven of vergelijkingen bevatten. Daarom moeten we, om de juiste vereisten te schrijven, de juiste informatie verkrijgen en de verzamelde informatie correct documenteren.

Toekomstige trends: vereisten schrijven met AI

Kunstmatige intelligentie (AI)-technologie heeft het potentieel om een ​​revolutie teweeg te brengen in de manier waarop vereisten worden geschreven en beheerd bij productontwikkeling. In de afgelopen jaren zijn er aanzienlijke vorderingen gemaakt op het gebied van natuurlijke taalverwerking (NLP) en machine learning (ML) die het mogelijk hebben gemaakt om bepaalde aspecten van requirements engineering te automatiseren.

Een mogelijke toekomstige trend is het gebruik van AI-gestuurde chatbots, zoals ChatGPT en Jasper, om te helpen bij het schrijven van vereisten. Deze chatbots gebruiken NLP-algoritmen om input van stakeholders te analyseren en op basis van die input hoogwaardige eisen te genereren. Door gebruik te maken van deze tools kunnen organisaties het requirements engineering-proces stroomlijnen, waardoor de tijd en moeite die nodig is om requirements te ontwikkelen, wordt verminderd, wat leidt tot snellere productontwikkelingscycli en een efficiënter gebruik van middelen.

Een andere potentiële trend is het gebruik van AI om automatisch vereisten te identificeren en te extraheren uit verschillende bronnen van ongestructureerde gegevens, zoals feedback van klanten, berichten op sociale media en productrecensies. Door NLP-algoritmen te gebruiken om automatisch relevante vereisten uit deze bronnen te identificeren en te extraheren, kunnen organisaties een dieper inzicht krijgen in de behoeften en voorkeuren van klanten, wat leidt tot succesvollere productontwikkelingsresultaten.

AI-technologie kan ook helpen om de kwaliteit en consistentie van vereisten te verbeteren door potentiële conflicten, onduidelijkheden of overbodigheden in de vereisten te identificeren. Dit kan helpen om het risico op fouten en misverstanden te verminderen, wat leidt tot een betere productkwaliteit en minder kostbare herbewerkingscycli.

Essentiële tips voor het schrijven van vereisten

1. Schrijf in lagen - Het schrijven van vereisten in lagen betekent het opsplitsen van complexe vereisten in kleinere, beter beheersbare stukken. Dit helpt om de vereisten begrijpelijker, uitgebreider en gemakkelijker te implementeren te maken.
2. Een per keer - Elke vereiste moet worden behandeld als een afzonderlijke testcase. Voegwoorden zoals en, of, enzovoort mogen niet worden gebruikt, omdat ze kunnen leiden tot het missen van vereisten. Dit is met name cruciaal omdat termen als deze ervoor kunnen zorgen dat softwareontwikkelaars en testers vereisten over het hoofd zien. Het opsplitsen van gecompliceerde behoeften in kleinere delen totdat ze allemaal afzonderlijk kunnen worden getest, is een manier om dit te voorkomen.
3. Praat 'wat' niet 'hoe' - De focus moet liggen op wat het systeem zal doen, niet hoe het het doet. Zorg er bovendien voor dat u niet te diep ingaat op ontwerponderwerpen zoals veldnamen, programmeertaalobjecten en software-objecten. Als je merkt dat je deze onderwerpen bespreekt in het Requirements Specification Document, doe dan een stapje terug – dit betekent waarschijnlijk dat je te specifiek wordt.
4. verifieerbaar – Een ander ding om in gedachten te houden bij het organiseren van vereisten is dat ze altijd toetsbaar moeten zijn. Dit betekent dat geverifieerd moet kunnen worden of het systeem voldoet aan de betreffende eis. Dit houdt ook verband met ons volgende punt: traceerbaarheid. Als een vereiste vol vage termen staat, wordt het moeilijker om te analyseren en te controleren of het systeem daadwerkelijk aan deze normen voldoet. Streef daarom zoveel mogelijk naar duidelijkheid en precisie in uw taalgebruik, zodat het verzamelen van vereisten geen dubbelzinnig proces is.
5. Traceerbaarheid – Traceerbaarheid in projectmanagement verwijst naar het verzekeren dat eisen gekoppeld zijn aan andere componenten in het project. Hierdoor kunnen projectmanagers, ontwikkelaars en belanghebbenden de volledige levenscyclus van een vereiste van begin tot eind volgen, zowel in alle richtingen als in andere delen van het systeem. Als je de traceerbaarheid goed beheert, kun je code vermijden die aan geen enkele eis voldoet ('verdwaalde' code) en ervoor zorgen dat elke testcase minimaal één eis dekt. U kunt vereisten traceerbaar maken door ze te labelen met een unieke identificatie en informatie over hun bron te verstrekken in een centrale opslagplaats die toegankelijk is voor alle teamleden.
6. De 3 W's – Vereisten moeten gericht zijn op het voldoen aan de behoeften van de gebruiker en niet op de oplossing. Daarom is het essentieel om de eisen en pijnpunten van de gebruiker te begrijpen alvorens de eisen te ontwikkelen.
   1. Wat? - Wat doen we?
   2. WHO? – Wie zal er baat bij hebben?
   3. Waarom? – Waarom doen we het?
7. 1 vereiste voor 1 taak - Elke vereiste moet een enkele actie en doelstelling vermelden. Pas op voor overmatig gebruik van "en" en "of". Bijvoorbeeld: "Als de laatste vrijdag van de maand en de betaling op de 31e moet worden betaald, en als de 31e de laatste vrijdag van de maand is, zal het indienen van de betaling op die dag na 6 uur Eastern Time resulteren in een te late betaling ”. Ik daag je uit om die te begrijpen!
8. Prioriteiten stellen – Prioriteer vereisten op basis van hun belang en impact op het succes van het project. Dit helpt ervoor te zorgen dat de belangrijkste vereisten als eerste worden geleverd en dat aan de behoeften van belanghebbenden wordt voldaan.
9. Geen ontsnappingsclausule - Bijvoorbeeld: “Het systeem bepaalt het aantal inlogpogingen, behalve wanneer de gebruiker duidelijk een onjuiste gebruikersnaam heeft ingevoerd”.

Wat onderscheidt volgens Jordan succesvolle projecten van mislukte projecten?

Wat volgens Jordan Kyriakidis succesvolle projecten onderscheidt van niet-succesvolle projecten, is het vermogen om vereisten effectief te beheren. Succesvolle projecten hebben een duidelijk begrip van de vereisten en zijn in staat om deze gedurende het gehele ontwikkelingsproces te managen, van de eerste planning tot de uiteindelijke oplevering. Aan de andere kant hebben niet-geslaagde projecten vaak te kampen met slecht eisenbeheer, wat kan leiden tot miscommunicatie, vertragingen en uiteindelijk het niet halen van de projectdoelen. Daarom is het voor bedrijven van cruciaal belang om te investeren in robuuste requirements engineering-praktijken en tools om het succes van hun projecten te garanderen.

Waar vind je meer over Jordan Kyriakidis?

Voor meer informatie over Jordan Kyriakidis en QRA Corp kunt u hun LinkedIn-pagina bekijken op https://www.linkedin.com/company/qra-corp/. Daarnaast kun je Jordan Kyriakidis op LinkedIn vinden op https://www.linkedin.com/in/jordankyriakidis/. QRA Corp heeft ook verschillende whitepapers en casestudy's beschikbaar op hun website die inzicht geven in de technologie en de toepassing ervan in verschillende industrieën.

Conclusie

Tot slot hebben Jordan Kyriakidis en Visure Solutions een verhelderend gesprek gedeeld over schrijfvereisten. We hebben het belang van het schrijven van uitstekende vereisten onderzocht en de uitdagingen bij het schrijven van vereisten besproken, samen met veelvoorkomende fouten. We hebben verschillende methoden bekeken, zoals natuurlijke taalmethoden, het EARS-sjabloon en INCOSE-richtlijnen. AI-technologie heeft ook veel mogelijkheden geopend voor het schrijven van vereisten, waardoor het gemakkelijker wordt voor mensen die beginnen te leren hoe ze deze beter kunnen schrijven. Ten slotte hebben we ook belangrijke tips opgenomen om u op weg te helpen terwijl u aan deze reis begint. Van leren over INCOSE-regels tot toekomstige trends in schrijfvereisten - er is hier voor elk wat wils! Haal deze essentiële tips weg en breng ze nu in de praktijk! Bekijk nu het volledige interview!