De vraag achter de vraag ontdekken
De afgelopen twintig jaar heeft de wereld van softwareontwikkeling een heuse revolutie meegemaakt. In een korte tijd is het vakgebied overgestapt van een lineair naar een iteratief ontwikkelproces. De dagen waarbij er eerst maanden werden uitgetrokken om nauwkeurig te specificeren wat een compleet systeem moest doen, zijn voorbij. Tegenwoordig leveren ontwikkelaars in korte cycli kleine brokjes functionaliteit op, die ze op basis van feedback steeds verder proberen te verbeteren. In die twintig jaar is er echter één ding constant gebleven: de meeste softwareprojecten falen.
Ze falen omdat er, ondanks alle inspanning, niet het juiste wordt gebouwd. De projecten blijken niet (of niet optimaal) het probleem op te lossen waarvoor ze in het leven zijn geroepen. Er gaat, kortom, iets mis op het vlak van requirements engineering. Het scherpstellen van de requirements – het ontdekken van de vraag achter de vraag – is misschien wel het belangrijkste onderdeel van het hele softwareontwikkelproces, maar blijkt tegelijkertijd een eeuwig ondergeschoven kindje.
Dat is ook wel te verklaren, want requirements engineering is… moeilijk. Heel moeilijk. Het achterhalen van de systeemvereisten vraagt een enorme inspanning van requirementsanalisten. Het op te lossen probleem is immers altijd vager, minder gedefinieerd dan de absolute precisie die software verlangt. Analisten moeten belanghebbenden de juiste vragen weten te stellen om een vertaalslag te kunnen maken van business naar IT.
Gelukkig hoeven ze dat niet alleen te doen. Handboek requirements van Nicole de Swart, waar onlangs de derde editie van is verschenen, is een onmisbare gids in dit proces. Het boek bevat een schat aan informatie over de verschillende typen requirements, de verschillen tussen de lineaire (of traditionele) en iteratieve (Agile) manier van requirements verzamelen, en een overzicht aan verschillende technieken die een analist kan gebruiken om de requirements scherp te krijgen. Hoewel het is geschreven voor analisten, hebben ook programmeurs en testers er baat bij kennis te nemen van De Swarts handboek.
Met name het contrast tussen de traditionele en Agile aanpak maakt het Handboek requirements de moeite waard. Dat is in de eerste plek zo omdat veel analisten opereren in een hybride omgeving. Maar belangrijker is dat het lezers in staat stelt om de voor- en nadelen van beide manieren op een rij te zetten. Of ze nu los van het ontwikkelteam zijn gesitueerd, zoals in de traditionele aanpak, of er een integraal deel van uitmaken, pas als analisten er weet van hebben dat het ook anders kan, kunnen zij hun werkwijze verbeteren. De grootste waarde in Handboek requirements zit hem in het in staat stellen van analisten om uit verschillende aanpakken te cherry picken wat voor hun situatie het best werkt.
Wat Agilisten bijvoorbeeld zal opvallen aan de traditionele aanpak is het loodzware proces en de enorme papierwinkel die erbij komt kijken. Dat is iets waar ze terecht afscheid van hebben genomen. Aan de andere kant kunnen zij wat leren van de tijd en zorg die vroeger werd genomen om de precieze wens te formuleren. Nog te vaak komt het voor dat ontwikkelaars met een vage notie van een gebruikerswens al naar hun toetsenbord grijpen. Geduld en een goed luisterend oor zijn echter hun vriend, al weten ze dat nog niet. Zo voorkomen ze een hoop rework verderop.
Toch is Handboek requirements niet voor iedereen weggelegd. Dat ligt niet zozeer aan de inhoud, maar eerder aan de vorm. Het boek leest bij tijden – het mag eigenlijk niet verbazen – zélf als een requirementsdocument: zo droog en eenduidig mogelijk. Hoewel het boek met zijn 288 pagina’s bepaald geen dikke pil is, maakt De Swarts schrijfstijl het een behoorlijke opdracht om er doorheen te komen. Wat dat betreft hadden de Agilisten toch een punt: de effectiefste manier om informatie te delen is door te praten.
Deze recensie verscheen ook in AutomationNL en op Bazarow.com.
agile ontwikkeling · boeken · informatieanalyse · recensies · requirements