Antwoord.

Achtergrond:

Vereisten traceren (traceability) ontstond als een hulpmiddel om discrepanties tussen de bedrijfsverwachtingen en de feitelijke implementatie van het systeem te voorkomen. Aanvankelijk vertrouwden analisten op handmatige controles en lijsten, wat uiterst inefficiënt was.

Probleem:

Bij afwezigheid van tracering gaat de verbinding tussen vereisten op verschillende niveaus verloren: bedrijfsdoelen → functionele vereisten → technische vereisten → testscenario's. Dit leidt tot fouten, ‘verloren’ vereisten en een slechte implementatie.

Oplossing:

De tracering van vereisten wordt opgebouwd als een keten van overeenkomsten met behulp van matrices, gespecialiseerde tools (Jama, DOORS, Jira/Zephyr) en sjablonen:

Een traceermatrix (traceability matrix) wordt gemaakt, waarbij de eenvoudigste structuur is:

Bedrijfsdoel Functionele vereiste Testscenario
BC-1 FR-1 TC-1
Artefacten worden getagd in de tools.
Bij elke wijziging op elk niveau wordt de keten opnieuw bekeken — er moet een verbinding zijn.
Het is belangrijk om regelmatig audits uit te voeren om ‘hangende’ vereisten of tests zonder koppeling aan doelen te identificeren.

Belangrijke kenmerken:

Duidelijke doorlopende verbinding van behoeften naar resultaten
Geautomatiseerde tracking in tools
Controle over de volledigheid en onderbouwing van vereisten en tests

Misleidende vragen.

Kan men zonder traceermatrix op een klein project?

Nee, zelfs op kleine projecten leidt het ontbreken van tracering vaak tot verlies van vereisten.

Is het voldoende om tracering eenmaal aan het begin van het project op te zetten?

Nee, de matrix vereist regelmatige updates naarmate de vereisten en tests veranderen.

Beïnvloedt tracering alleen de afronding van de tests?

Nee, het is belangrijk in alle fasen — van ontwerp tot onderhoud, het helpt om de impact van wijzigingen te evalueren en werk te plannen.

Typische fouten en anti-patronen

Willekeurige, en geen systematische tracering
Ontbreken van audits van ketens bij wijzigingen
Negeren van irrelevante of hangende vereisten

Voorbeeld uit het leven

Negatieve case:

In het project werd geen traceermatrix opgebouwd, testers baseren zich alleen op de specificatie. Verschillende vereisten zijn geïmplementeerd, maar niet getest, waardoor functies in productie niet naar behoren werkten.

Voordelen:

Project sneller gestart

Nadelen:

Gemiste kritische fouten, frustratie bij de klant

Positieve case:

In een ander project werd een actieve traceermatrix bijgehouden. Alle vereisten werden gekoppeld aan tests en bedrijfsdoelen, alle wijzigingen werden bijgehouden. Er waren geen ongeaccountabiliseerde functies of ‘niet-gedocumenteerde’ tests.