Tag requirements
Tijdreis
Ik vroeg mijn collega’s: “Wat doet dit ding precies?” - waarop ze prompt de code tevoorschijn haalden en me stap voor stap door het importproces loodsten. Het was alsof ik terug werd geslingerd naar het begin van mijn ontwikkelcarrière, toen we met z’n allen een twaalf jaar oude legacy applicatie onderhielden die alleen te doorgronden was door nauwgezet de code te doorlopen. Wat blijkt: tijdreizen bestaat - je hoeft alleen maar bij een ander team te buurten.
De vraag achter de vraag ontdekken
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 is een onmisbare gids in dit proces.
Wij van TDD-eend...
Het is waar: uit het feit dat er tests zijn, valt niet te concluderen dat het systeem functioneert zoals verwacht - preciezer: zoals de eindgebruiker verwacht. Er valt hooguit uit te concluderen dat het systeem functioneert zoals de schrijver van de tests verwachtte. En als de schrijver van de tests tevens de ontwikkelaar van de code is, dan vormen de tests niet meer dan een verslaglegging van de aannames die de ontwikkelaar had tijdens de implementatie. En tóch geloof ik dat TDD het probleem van mijn collega - mijn feature voldoet niet aan de (impliciete?) requirements - had kunnen verhelpen.
Aantekeningen over requirements - deel 2
Het opstellen van de juiste requirements is één van de moeilijkste onderdelen van softwareontwikkeling. In een eerdere blog beschreef ik de eerste acht lessen die Karl Wiegers of dit onderwerp formuleerde in Software Development Pearls. In deze blog volgen de tweede acht.
Aantekeningen over requirements - deel 1
Het moeilijkste onderdeel van softwareontwikkelen is niet het juist bouwen, maar het juiste bouwen. Vaak zwoegen programmeurs dagenlang op hun code en worstelen testers zich door het resultaat heen, om er pas helemaal op het eind van de ontwikkelcyclus achter te komen dat er iets is gebouwd waar eindgebruikers niet helemaal (of: helemaal niet!) op zaten te wachten. Het scheppen van een juist beeld van wat er gemaakt moet worden is misschien wel de belangrijkste stap in het ontwikkelen van software - en niet zelden de minst ontwikkelde.