Hoe requirements traceability het beste ingericht kan worden.

4.3 Project en domein BBMS
Ten behoeven van het onderhoud aan het spoor wordt meetdata en videodata verzameld over de
status van het spoor. Deze data wordt gebruikt door andere partijen voor het onderhoud aan het
spoor. Vanuit de wens één centraal punt van dataverzameling en beheer te hebben waarbij ProRail de
regie voert in de branche is de wens ontstaan om het Branche Breed Monitoring Systeem te
ontwikkelen. Het project is aanbesteed en leidt tot een leverancier die het systeem met alle
bijbehorende facetten zal gaan leveren. De insteek is vooralsnog dat ProRail alles zelf zal beheren.
Het systeem voorziet dus in het opslaan, en categoriseren van data en beeldmateriaal, analyseren
van data en beeldmateriaal, rapporteren en het ontsluiten van data en beeldmateriaal en analyses aan
derde partijen. Dit systeem zal bestaan uit een standaard pakket met daarbij de nodige uitbereidingen
specifiek voor ProRail. Ook zal gewerkt gaan worden met een webeditie waarvan ProRail de eerste
zal zijn die hier gebruik van maakt. Deze is dan ook grotendeels voor ProRail ontwikkeld. Het project
stelt geen hoge eisen aan beschikbaarheid en beveiliging. Wel is betrouwbaarheid en integriteit van
de data zeer belangrijk. Er is sprake van complexe data waarop analyses worden gedaan. Deze
analyses en de resultaten dienen nauwkeurig en correct te zijn.
Omdat er sprake is van een standaard pakket en de webeditie door de leverancier ook als standaard
pakket geleverd wordt is er sprake van ‘slechts aanvullend maatwerk’. Dat houdt in dat op een aantal
punten ProRail additionele wensen heeft waarvoor software gebouwd en/of aangepast wordt. Voor
deze onderdelen zijn Functioneel Ontwerpen opgesteld. Op basis hiervan bouwt de leverancier dit
maatwerk. Voorbeeld van de inhoud van een dergelijk Funtioneel Ontwerp is ook opgenomen in
Bijlage II.
4.3.1 Requirements structuur BBMS
In het project Branche Breed Monitoring Systeem (BBMS) is ervoor gekozen de opbouw van
requirements als volgt in te delen. Men is begonnen met het onderscheid in functional en nonfunctional
om vervolgens daarbinnen weer een opsplitsing te doen in proces/activiteit, daarna volgt de
indeling naar de structuur van MoSCoW. Wat op valt bij het project BBMS is dat de wijze van
vastlegging volgens de eerder beschreven structuur geen onderscheidt maakt in het soort
requirement. Elke soort requirement wordt op dezelfde wijze door de beschreven boomstructuur
vastgelegd.
Dit ziet er schematisch dus als volgt uit:
Figuur 26 'Requirements structuur BBMS'. Bron:
Kanttekening hierbij is wel dat wanneer je kritisch naar de requirements kijkt bijvoorbeeld niet alle
requirements uit hoofdstuk 9 gedefinieerd kunnen worden als non-functionals. De structuur is dus niet
heel zorgvuldig gehanteerd.
39