Dutch post: Meer heldere requirements: vermomde processen

De laatste paar dagen hebben verschillende mensen mij dezelfde vraag gesteld: “Hoe kunnen we meer heldere requirements krijgen”. Hoewel ik het eens ben dat het niet netjes is om een vraag met een vraag te beantwoorden, is het in mijn visie beter om in dit geval soepel om te gaan met die etiquette. En wel  omdat deze vraag eigenlijk niet zo eenvoudig te beantwoorden is. Bijvoorbeeld, waarom is dit nodig en welk probleem lost het op? Of, wat bedoel je precies met helder? En heb je heldere requirements en wil je er meer? En in dat geval, meer dan wat? Of heb je requirements die niet helder zijn en die je beter wilt kunnen communiceren. En zo ja, hoeveel beter?

Je zou kunnen zeggen dat dit gewoon spelen met woorden is. En dat klopt! Maar is het formuleren en communiceren van requirements niet feitelijk hetzelfde? Voor meer heldere requirements zijn een tal van zaken benodigd. Er is echter een belangrijk element dat vaak over het hoofd wordt gezien, namelijk inzicht in de structuur van taal en de wijze waarop taal wordt geïnterpreteerd.

Daniel, een goede vriend van mij, vertelde me eens wat hij had meegemaakt met een projectteam dat goed in de problemen zat met zogenaamde niet-functionele systeemeisen. Het team wist dat er niet-functionele eisen waren die cruciaal waren voor het slagen van het project. Echter, de klant werkte in hun ogen niet echt mee en was ook niet in staat om deze eisen goed te verwoorden. Uiteindelijk werd een doorbraak geforceerd met behulp van het conflictmodel: (lees hardop: “Dus je wilt een systeem dat niet te gebruiken is en waardoor alle gebruikers met de dag steeds meer gefrustreerd raken”. Het schokeffect creëerde inderdaad een opening, maar ik ben er zeker van dat jij het met mij eens bent dan de meeste klanten het niet op prijs stellen om te worden gebruuskeerd, toegeschreeuwd of afgebekt. En gelukkig zijn er een meer vriendelijkere en elegantere manieren.

Neem bijvoorbeeld niet-functionele requirements zoals: betrouwbaarheid, gebruiksvriendelijkheid, efficiency, onderhoudbaarheid, portabiliteit en stel jezelf de volgende vraag: Wat hebben deze kwaliteitsattributen gemeenschappelijk vanuit het oogpunt van taal? Het antwoord is dat het allemaal zelfstandig naamwoorden zijn terwijl het eigenlijk werkwoorden zijn. Of met andere woorden, het zijn vermomde actieve processen die worden behandeld alsof het (fysieke) dingen zijn. Dit fenomeen kom je overigens overal tegen in allerhande situaties. Wanneer iemand je bijvoorbeeld vertelt dat hij of zij een depressie heeft, dan voelt die persoon zich eigenlijk gewoon naar. En hetzelfde is aan de hand met plezier of lol. Je hebt geen plezier, je voelt je goed.

Op dit punt vraag je je wellicht af waarom het gebruik van zelfstandig naamwoorden in plaats van werkwoorden nu eigenlijk een probleem is. Het blijkt dat het veel lastiger is om een probleem op te lossen wanneer het achterliggende proces verstopt of verborgen is. En in ons specifieke geval betekent het dat het veel lastiger is om requirements helderder of meer precies te specificeren en te communiceren. Zo is de kans op het gebruik van jargon veel groter als je processen behandelt alsof het dingen zijn: “Aha beschikbaarheid, en wat is dan de mean time between failure”. En voordat je het weet is de klant je al helemaal kwijt. Meer fundamenteel beschouwd is het zo dat het brein dingen als statisch of onveranderbaar ervaart terwijl processen impliciet als veranderlijk en dynamisch worden ervaren. En dit betekent dat wanneer je vanuit proces redeneert het veel makkelijker is om tot de essentie te komen en de helderheid van requirements te verhogen. En het betekent ook dat je beter in staat bent om over requirements te onderhandelen of de impact te reduceren zodat waarde kan worden geleverd tegen realistische kosten en doorlooptijd.

Laten we een concreet voorbeeld nemen. Een klant zou het volgende requirement of systeemeis kunnen opgeven

  • Het systeem moet een beschikbaarheid hebben van 100%.

Sommige analisten zullen direct de haalbaarheid of realiteitszin van 100% beschikbaarheid ter discussie stellen met een grote kans om de klant kwijt te raken. Wanneer je genoeg weet van het probleemdomein en de klant het jargon begrijpt, dan is vragen stellen over de onderliggende processen een elegantere aanpak, bijvoorbeeld:

  • Wat is de gemiddelde tijdspanne in een jaar dat het systeem niet beschikbaar mag zijn?
  • Wat is de gemiddelde tijdspanne in een jaar dat het systeem niet beschikbaar kan zijn ten behoeve van onderhoud?
  • Wat is de maximum toegestane tijdspanne benodigd om het systeem opnieuw te starten nadat het niet beschikbaar is geweest?

En wanneer je eigenlijk geen idee hebt wat de klant nu eigenlijk echt wil of wanneer je vermoed of weet dat de klant concepten als beschikbaarheid niet helemaal begrijpt, dan is het eleganter om meer contextvrije vragen te stellen zoals:

  • Hoe is het om een systeem te hebben dat 100% beschikbaar is?
  • Wat zou er gebeuren wanneer het systeem maar 90% van de tijd beschikbaar is?

Ik kan niet garanderen dat klant meteen alle antwoorden heeft, maar in bijna alle gevallen zal de discussie  nu eenvoudiger en vriendelijker verlopen omdat we het proces achter het requirement hebben gedenominaliseerd.

Een goede manier om nominalisaties of vermomde processen te detecteren is door te testen of je het onderwerp (zelfstandig naamwoord) van de zin in een doos kunt stoppen, ook al is het een enorm grote doos. Of dat je het uit het raam kunt gooien of in een kruiwagen kunt stoppen. Wanneer dat niet mogelijk is, ga dan op zoek naar de onderliggende processen. Kun je gebruiksvriendelijkheid in een doos stoppen? Of beschikbaarheid? Of software?

Een standaard zoals ISO/IEC 25000 geeft categorieën en belangrijker metrics, ten behoeve van evaluatie en verificatie van niet-functionele requirements of kwaliteitsattributen. Deze metrics geven een uitstekend startpunt voor het doorgronden en verkennen van de onderliggende processen.

Er zijn nog veel meer taalpatronen die, wanneer ze worden overtreden, de effectiviteit van communicatie negatief kunnen beïnvloeden. In alle gevallen gaat het om het verdraaien, weglaten of (over)generaliseren van de werkelijkheid. En in mijn visie is dit een belangrijke bron van obstakels die je vaak moet overwinnen wanneer je behoefte hebt aan meer heldere requirements of andere problemen op dit vlak hebt op te lossen.

De lijst met taalpatronen is te omvangrijk om hier te bespreken en wellicht iets voor een volgende keer. Mocht je meer willen over taalpatronen, dan is het NLP meta-model een uitstekende bron. Maar plaats gerust een reactie wanneer je meer wilt weten of vragen hebt.

2 Comments
  1. Arthur de Snaijer | November 14, 2010 at 2:32 am Reply

    avatar

    Lijkt me een kwestie van luisteren en feedback. En met feedback bedoel ik hier show THE value and learn.

  2. Giel Raijmakers | September 27, 2010 at 6:36 am Reply

    avatar

    Enkele jaren geleden was bij LaQuSo (http://www.laquso.com/) een hele middag over kwaliteit van documentatie, een van de keyspeakers (ben zijn naam kwijt) was al 25 jaar bezig met het helder maken van documentatie… en hij is er nog altijd niet uit.
    Een van zijn tips die me bij is gebleven, tabellen. Plaatjes en tabellen zeggen meer dan 1000 woorden. Is een oude bekende, maar het is wel zo.

    “mary had a little lamb”(een voorbeeld vanuit een eurostar presentatie.) Wat staat er?
    mary had een klein lammetje, mary had een stukje lam, mary heeft een lam voor de gek gehouden… Wat is het??
    Zoveel lezers, zoveel meningen. Door zoveel mogelijk met tabellen te werken is het snel en overzichtelijk.