Antwoord.

Geschiedenis van de vraag:

Vroege fasen van projecten worden vaak gekenmerkt door onvoldoende duidelijkheid over zakelijke doelstellingen en architectonische oplossingen, waardoor de systeemanalist wordt geconfronteerd met de uitdaging om het optimale niveau van detail in de vereisten vast te stellen. Een verkeerde keuze leidt ofwel tot overmatige uitwerking (overengineering) of tot vaagheid van taken en onduidelijkheid binnen het team.

Probleem:

Sommige belanghebbenden willen details "aan de wal" zien, terwijl anderen bang zijn dat overmatige detaillering leidt tot verlies van flexibiliteit. De overgang tussen fases (van concept naar ontwerp, dan naar implementatie) vereist tijdige bijwerking van vereisten en betrokkenheid van alle deelnemers.

Oplossing:

De systeemanalist hanteert een iteratieve aanpak. In de vroege fases worden alleen de belangrijkste zakelijke behoeften en grote blokken (epics) vastgelegd, waarna de niveaus van detail toenemen naarmate de ontwikkeling vordert:

In de presalesfase — Visie en high-level vereisten;
Bij de voorbereiding van de technische specificaties — decompensatie tot user stories of feature-specificaties;
In de ontwerpfase en overdracht naar ontwikkeling — uitwerking van scenario's, fouten, interacties en mockups tot het niveau van acceptatiecriteria.

Belangrijke kenmerken:

De detaillering groeit naarmate de oplossing verfijnd wordt (principle of progressive elaboration).
De analist gebruikt synchronisatie met het team om niet te vroeg in details te verzanden.
Het niveau van detaillering wordt afgestemd op de levenscyclus van het project en contractuele verplichtingen.

Vragen met een valkuil.

Wie moet het vereiste niveau van detaillering bepalen — de analist, architect of opdrachtgever?

Gaandeweg wordt vaak ten onrechte gedacht dat alleen de analist of alleen de architect dit doet, maar het juiste antwoord is: het niveau van detaillering is de verantwoordelijkheid van de hele coördinatiegroep (analist, architect, product owner, technische leiders en opdrachtgever), goedgekeurd in het kader van de projectmethodologie.

Zijn high-level vereisten voldoende om het team aan het werk te zetten?

Nee, high-level vereisten zijn nodig om een algemeen beeld te vormen. Voor de overgang naar ontwikkeling zijn gedetailleerde scenario's (user stories, acceptatiecriteria) absoluut noodzakelijk, anders is er een groot risico op misverstanden en fouten bij de implementatie.

Moeten alle vereisten even gedetailleerd zijn bij de release?

Nee, vaak worden de vereisten voor MVP zo diep mogelijk uitgewerkt, terwijl minder prioritaire taken op het niveau van concepten blijven om middelen niet voortijdig te verspillen.

Veelvoorkomende fouten en anti-patronen

Men blijft de detaillering verhogen zonder rekening te houden met de fase van het project.
Men begint met het uitwerken van de details van alle vereisten, zelfs de minder prioritaire, waardoor de snelheid verloren gaat.
Men negeert communicatie met het team over de toereikendheid van de detailvorming — er ontbreekt feedback.

Voorbeeld uit de praktijk

Negatieve case: CRM-project in een startup. Het bedrijfsleven drong aan op volledige uitwerking van alle modules vooraf. De analist stelde honderden pagina's vereisten op voor alle toekomstige functies, terwijl alleen de verkoop prioriteit had.

Voordelen:

Gedetailleerde basis van vereisten voor de toekomst.

Nadelen:

Tijd- en budgetkosten, vertragingen in de start.
De vereisten waren verouderd tegen de tijd dat de modules aangepast moesten worden en vereisten aanzienlijke wijzigingen.

Positieve case: In een vergelijkbaar project heeft de analist de kernvereisten voor het MVP (beheer van leads en deals) opgesteld, terwijl de overige als epics met een korte beschrijving zijn vastgelegd. De detailing verliep tijdens de voorbereiding van de implementatiesprints.