Een leven lang zorgen (13)

Vorige week is collega Piet de Roo ingegaan op technieken om requirements te achterhalen. Maar wanneer we die requirements eenmaal hebben, hoe lang moeten we ze dan meenemen door het project heen?

Nou, tot ze opgepakt zijn door een architect of ontwerper en gevangen zijn in een ontwerpdocument bijvoorbeeld. Dat zou best valide kunnen zijn. Ze zijn tenslotte opgepakt en verwerkt. In alle fasen daarna hoeft er niet meer gekeken te worden naar de requirements, die zitten nu immers in ontwerpdocumenten. Toch?

Ja en nee zou je kunnen zeggen.

Ja wanneer we controleren dat alle requirements op juiste wijze vertaald in de ontwerpdocumentatie terecht zijn gekomen. Maar over welke ontwerpdocumentatie hebben we het dan? Waarschijnlijk hebben we te maken gehad met verschillende stakeholders die vanuit hun visie op het te ontwikkelen systeem met requirements zijn gekomen. De kans is groot dat deze informatie vanuit die verschillende visies ook in verschillende ontwerpdocumenten komt te staan. Vanuit een gebruiker kijken naar een systeem zal een ander document opleveren dan wanneer het systeem vanuit een functioneel of technisch beheerder wordt beschreven. Documentatie vanuit verschillende gebruiksdoeleinden.

En wat nu wanneer we het hebben over een zeer complex systeem? Opgebouwd uit vele, op zichzelf ook weer complexe, subsystemen? Waarbij na het eerste niveau van ontwerpdocumenten (functioneel, systeem documentatie), er nog verdere uitwerking in andere ontwerpdocumenten nodig is (subsysteem en/of technische documentatie). Documentatie vanuit gelaagdheid van het systeem.

We kunnen ook het aspect tijd en het overdragen van informatie er bij betrekken. We kennen van vroeger allemaal wel de oefening waarbij we in een groep een verhaal aan elkaar door moesten vertellen, 1 op 1, zonder dat de anderen daar wat van mee kregen. De laatste persoon moest vervolgens aan de eerste persoon vertellen wat hij te horen had gekregen. Nou dat verhaal leek dan nog niet ‘bijna’ op het verhaal waarmee de eerste persoon begonnen was. Hilariteit alom. In een dergelijke setting wel, maar in het werk willen we dat helemaal niet meemaken.

Waarschijnlijk doen we er verstandig aan de requirements veilig te stellen en mee te nemen tijdens het gehele ontwikkeltraject. Hierdoor zijn we in staat om, in de tijd, de requirements er bij te pakken. Te controleren, wanneer we documentatie schrijven en opleveren, of een en ander compleet en consistent is en nog steeds aansluit bij wat de stakeholders voor ogen hebben. De overdracht van de informatie.

In de praktijk zal het antwoord veelal nee zijn. We zullen requirements mee moeten nemen door het gehele ontwikkeltraject. Dat is een optie wanneer we daarin een keuze kunnen maken. Omvang, complexiteit en gelaagdheid zijn daarbij zaken die een rol spelen. Maar in bepaalde omgevingen is het ook simpelweg verplicht. Traceerbaarheid: aan kunnen tonen dat een requirement aangedragen door een stakeholder, uiteindelijk op juiste wijze in het systeem terecht is gekomen. Dan hebben we het naast documentatie over het koppelen aan de softwarecode tijdens het software ontwikkeltraject. Maar ook over het koppelen aan testontwerpen (test gevallen) en het resultaat van het uitvoeren van deze testgevallen. Een verplichting is hard wanneer deze door wet- of regelgeving wordt afgedwongen. Maar ook een opdrachtgever zou er natuurlijk om kunnen vragen.

Eerder had ik het over dat requirements, en daarmee de betrokkenheid van de requirements engineer, ‘het gehele ontwikkeltraject’ door gaat. Maar wanneer stopt die betrokkenheid dan? Wanneer het ontwikkeltraject ten einde is? Of nemen we ook het uiteindelijk beheer van een systeem hier nog in mee?

Ik denk dat het nooit stopt: Aan een systeem zal altijd ontwikkeld blijven worden. Veranderende requirements, nieuwe requirements. En als de veranderingen in het systeem verwerkt zijn, staan de volgende veranderingen al weer op de planning. Zelfs wanneer een systeem met pensioen gaat, uitgefaseerd wordt en het niet meer gebruikt wordt. Zelfs dan kan ik me voorstellen dat requirements van het uitgefaseerde systeem waarde blijven houden: ze kunnen bijvoorbeeld als inspiratiebron dienen voor de requirements van een nieuw te ontwikkelen systeem. Of we hebben ze nog nodig nieuw ontwikkelde systeem de organisatie toch niet heeft opgeleverd wat ze er van verwacht hadden.

Zorg goed voor requirements en houd ze levend: ze verdienen het!

Dit artikel is een artikel in de reeks over het veelzijdige vak van Requirements Engineering waarbij de komende maanden iedere week een collega van Improve Quality Services de lezer meeneemt in de zaken waar de Requirements Engineer vandaag de dag tegenaan loopt. Elk artikel zal herkenbaar zijn aan de brug, de verbinding tussen twee oevers, die symbool zal staan voor ons vak: de verbinding tussen twee partijen die goed willen samenwerken, door goed te communiceren en die wij daar graag in willen helpen.

Tot zover verschenen in deze reeks:

1. Requirements (Piet de Roo, 1 december 2020)

2. Shared Understanding (Kaspar van Dam, 8 december 2020)

3. Context en requirements structuur (Patrick Duisters, 15 december 2020)

4. Van Twin Peaks naar Twin Pines (Patrick Duisters, 22 december 2020)

5. Modellen om te bouwen (Erwin Pasmans, 5 januari 2021)

6. Minimaal Modelleren (Piet de Roo, 12 januari 2021)

7. Begrip en Vertrouwen (Benjamin Timmermans, 19 januari 2021)

8. En wat als de specialisten het niet met elkaar eens zijn? (Benjamin Timmermans, 26 januari 2021)

9. Waar zijn we nou helemaal mee bezig?! (Erwin Pasmans, 2 februari 2021)

10. Soft skills? Keiharde wetenschap! (Kaspar van Dam, 9 februari 2021)

11. … en nu enkele feiten: Requirement Attributen (Patrick Duisters, 16 februari 2021)

12. Waarom, waarom, waarom, ... (Piet de Roo, 23 februari 2021)