Antwoord.

Achtergrond van de vraag

Aan het begin van een groot project is het vaak noodzakelijk om de vereisten zo snel mogelijk te verzamelen en te structureren, aangezien het bedrijf een snelle marktintroductie vereist. Dit leidt vaak tot formaliteit en verlies van details, waardoor de technische schuld en het aantal aanpassingen na de MVP toenemen.

Probleem

De belangrijkste uitdaging is de balans tussen snelheid en kwaliteit van de vereisten. Oppervlakkig verzamelen leidt tot fragmentatie en een toename van wijzigingen in de implemenatiefase, terwijl te grondig werk de voortgang vertraagt en marktkansen belemmert.

Oplossing

• Vorming van een hiërarchie van vereisten: snelle verzameling van high-level vereisten met een daaropvolgende gefaseerde detaillering (rolling wave planning).
• Het houden van facilitator-sessies en workshops met verschillende stakeholders (Design Sprint, Event Storming).
• Het toepassen van sjablonen voor user story mapping en priorizationsmatrix voor het snel identificeren van de "kern" van het product.
• Invoering van een transparant pre-grooming proces: alleen de belangrijkste scenario's uitwerken met aanduiding van risico's en onduidelijkheden.
• Nadruk op visualisaties (proceskaarten, prototypes) om vervorming van vereisten tot een minimum te beperken.

Belangrijke kenmerken:

• Gebruik van agile benaderingen voor prioritering en gefaseerde detaillering van vereisten.
• Formalisering van onduidelijkheden in plaats van het negeren van niet-ontwikkelde vereisten.
• Regelmatige reviews en betrokkenheid van het ontwikkelteam voor tijdige identificatie van technische beperkingen.

Vragen met een addertje onder het gras.

Is het mogelijk om de start van het verzamelen van vereisten te versnellen door af te zien van documentatie van secundaire scenario's?

Nee. Ze moeten worden vastgelegd als risicogebieden of onontwikkeld, anders "komen ze naar boven" in latere fasen en leiden ze tot aanpassingen.

Moeten alle gevonden vereisten al aan het begin gevalideerd worden?

Alleen de belangrijkste. De overige moeten worden gemarkeerd als "onder voorbehoud van verduidelijking" en later in de komende iteraties worden behandeld.

Kunnen alleen bedrijfsvertegenwoordigers met vereisten werken?

Nee, technische specialisten moeten ook betrokken worden, aangezien veel beperkingen en architectuurkeuzes alleen gezamenlijk kunnen worden geïdentificeerd.

Typische fouten en anti-patronen

• "Verzonken" alleen in de happy path, zonder focus op uitzonderingsscenario's.
• Formalisatie van niet-gedetailleerde vereisten.
• Ontbreken van een re-review fase aan het begin.

Praktijkvoorbeeld

Negatief geval: In een groot project werden voor een snellere opstart alleen de belangrijkste bedrijfsprocessen uitgewerkt, waarbij de nuances van secundaire scenario's werden genegeerd. Voordelen: Snelle prototyping en uitrol van de MVP. Nadelen: Veel retouren voor rework, vertraging van releases en conflicten met het QA-team.

Positief geval: De analist verdeelde het proces in fasen, documenteerde risicogebieden, introduceerde procedures voor wekelijkse verduidelijkingen en prototype-ontwikkeling. Voordelen: Vermindering van retouren, transparantie van onduidelijkheid voor het team. Nadelen: Hogere belasting voor analisten in de eerste weken.