“Voordat je kunt schrijven, moet je weten wie de gebruiker is, hoe het product zal worden gebruikt, wat de context is en welke standaarden van toepassing zijn”.

Gepubliceerd op: 14 november 2025

Expert:

Katarzyna Kot MSc

Trainer

Lees meer over Katarzyna Kot

Deel

---

Iedereen die ooit betrokken is geweest bij productontwikkeling weet dat misverstanden in het beginstadium later tijd en geld kosten. Toch hebben veel projecten nog steeds moeite om duidelijk te definiëren wat er gebouwd moet worden. Katarzyna Kot, systeemingenieur en lid van de INCOSE Requirements Working Group, ziet dit elke dag gebeuren. Ze heeft het haar missie gemaakt om professionals te leren hoe ze effectiever requirements kunnen schrijven en begrijpen.

“Mijn hart ligt bij productontwikkeling”, zegt Katarzyna. “Je wilt iets tastbaars opleveren, maar dat lukt alleen als de basis stevig is. Daarvoor heb je duidelijke requirements nodig.”

Katarzyna kwam in 1998 vanuit Polen naar Nederland om te werken bij Philips ASA labs in Eindhoven. “Ik schreef code, ontwierp software, testte producten en raakte gefascineerd door wat er daarvoor allemaal gebeurt.”

Katarzyna Kot, trainer ‘Praktisch Requirements Schrijven’.

Na twaalf jaar bij Philips en NXP Semiconductors werkte ze als consultant voor klanten als BAE Aerospace en ASML. Het schrijven van requirements lijkt een eenvoudig proces: verzamelen, analyseren, valideren, documenteren. In de praktijk vergt het echter veel voorbereiding. “Mensen lopen vaak vast met de vraag wat ze nu eigenlijk moeten doen.”

De workshop

Om teams te helpen hun requirements op papier te zetten, ontwikkelde Katarzyna rond 2017 haar eerste workshops. Wat begon als op maat gemaakte in-company sessies is uitgegroeid tot een tweedaagse training genaamd‘Practical Requirements Writing‘, die nu openstaat voor een breder publiek.

De workshop is bedoeld voor iedereen die betrokken is bij requirements, zoals productmanagers, systeemarchitecten, QA-specialisten en domeinexperts. “We kijken naar de hele levenscyclus van een product,” legt Katarzyna uit. “In elke fase zijn er verschillende stakeholders en dus ook verschillende soorten requirements.”

Deelnemers leren hoe ze de behoeften van belanghebbenden kunnen analyseren, contextdiagrammen kunnen maken, vereisten kunnen structureren en de kwaliteit ervan kunnen beoordelen op volledigheid, consistentie, haalbaarheid, correctheid en verifieerbaarheid. “We werken met praktijkcases zodat deelnemers wat ze leren meteen kunnen toepassen. Het is handig als ze hun eigen requirements meebrengen, zodat we die samen kunnen beoordelen en verbeteren.”

De workshop is vooral nuttig voor professionals met een paar jaar ervaring. “Ze herkennen de uitdagingen uit de praktijk en denken meteen na om er beter mee om te gaan. Zodra ze vragen gaan stellen als ‘Hoe pas ik dit toe in mijn organisatie?’ of ‘Hoe overtuig ik mijn collega’s?’ kijken ze verder dan de oppervlakte.”

Uitdagingen

Kwaliteitseisen kunnen lastig te definiëren zijn. Vage termen zoals robuust of gebruiksvriendelijk moeten gekwantificeerd worden. “Als je zegt dat iets draagbaar moet zijn, wat betekent dat dan? Gewicht, afmetingen? Je vertaalt abstracte termen naar meetbare eigenschappen. Zo wordt kwaliteit concreet en testbaar.”

Het is ook belangrijk om te weten wanneer je moet stoppen. “Requirements moeten geschikt zijn voor het niveau waarvoor ze bedoeld zijn. Er moeten niet te weinig details zijn, maar specificeer ook niet te veel.”

Deelnemers worden vaak enthousiast als ze eenmaal begrijpen waarom requirements zo cruciaal zijn. “Sommige mensen hebben de waarde nog nooit goed uitgelegd gekregen. Maar zodra ze zien hoe het werk bijdraagt aan het grotere geheel, beginnen ze trots te worden.”

Denken

Requirements definiëren wat moet worden geleverd. Ze vormen de basis voor ontwerp en testen en hebben zelfs contractuele waarde. In industrieën zoals lucht- en ruimtevaart en halfgeleiders is het hebben van de juiste eisen een wettelijke noodzaak.

Toch worstelen veel organisaties er nog steeds mee. “Mensen vinden het vaak saai of weten niet waar ze moeten beginnen,” zegt Katarzyna. “Ze zien de waarde niet meteen omdat het wekenlang nadenken is zonder zichtbare output.”

Ze vergelijkt het schrijven van eisen met het plannen van een bouwproject. “Voordat de bouw begint, beslis je waar de stopcontacten komen, waar de lampen hangen en waar de keuken- en wasmachineaansluitingen moeten komen. Je documenteert deze beslissingen zodat de aannemer precies kan leveren wat je verwacht. Dat is wat eisen doen, ze voorkomen verrassingen voor zowel de klant als de leverancier.”

Voordat je kunt schrijven, voegt Katarzyna eraan toe, moet je weten wie de gebruiker is, hoe het product zal worden gebruikt, wat de context is en welke standaarden van toepassing zijn. “Dat zijn allemaal technische vaardigheden.”

Een belangrijk deel van de workshop gaat over sjablonen en schrijfregels, zoals de Easy Approach to Requirements Syntax (EARS). “Dat helpt dubbelzinnigheid te voorkomen, maar het is geen invuloefening. Je moet begrijpen wat je schrijft. Een tool kan helpen – maar je moet nog steeds nadenken.”

Katarzyna ziet ook potentieel in kunstmatige intelligentie. “AI begrijpt de context niet en kan geen vereisten schrijven, maar het kan wel helpen bij het analyseren ervan – bijvoorbeeld door inconsistenties op te sporen.”

Haar advies voor zowel AI als sjablonen: “Gebruik technologie als assistent, niet als vervanging van je eigen denkvermogen.”

Engineering

Wat Katarzyna het liefst wil benadrukken: “Requirements gaan niet over schrijven – ze gaan over engineering.”

Ze lacht. “Een collega uit de VS zei dat ooit, en ik zou het graag op een tegel gedrukt willen hebben. Want dat is precies wat het is: goede specificatie is geen administratie – het is ontwerpen met woorden.”

Dit artikel is geschreven door Marleen Dolman, freelancer voor High Tech Systems.