Systems Requirements Engineering – deel 5, tooling

In elke training duikt de vraag op: wat is voor ons de beste tool om onze requirements te beheren? Om deze vraag te beantwoorden zou je de toeters en bellen van alle requirements management tools moeten kennen, inclusief de laatste updates. Tegelijkertijd heb je een goed begrip nodig van de bedrijfsomgeving waar je deze tool wil inzetten. Ik kan er kort over zijn: dit is een schier onmogelijke taak.

Geen nood, er valt best een eerste onderscheid te maken. Het is handig om dat te doen op basis van het type business. Een organisatie als ASML is bijvoorbeeld niet verplicht zich te houden aan internationale veiligheidsnormen, informatiebeveiliging of FDA-voorschriften. Dan kan zelfs Word of Excel volstaan om de boel te beheren – verrassend genoeg geniet dat zelfs vaak de voorkeur.

Zodra normen en voorschriften van toepassing zijn, moet de software audit trails ondersteunen. Dat betekent basisfunctionaliteit bieden voor configuratiebeheer, zoals versiebeheer, wijzigingsbeheer en statusadministratie. Het is verbazingwekkend, maar veel requirements management tools bieden deze basisfuncties niet.

Een ander onderscheidend kenmerk is de baseline. In zijn meest elementaire vorm is een baseline een momentopname van de requirements database, die een subset van requirements bevat. Meer geavanceerde tools bieden workflows om specifieke requirements met specifieke kenmerken uit de database te selecteren. Een dergelijke baseline kan worden beoordeeld, gewijzigd, goedgekeurd en vrijgegeven als een afzonderlijke entiteit in de tool. Eenmaal vrijgegeven kan de inhoud van de baseline niet meer worden gewijzigd.

In sommige bedrijfstakken, zoals de automobielindustrie, is het uitwisselen van baselines tussen oem en leveranciers al enkele decennia de standaard werkwijze (beter bekend als de Lastenheft-Pflichtenheft informatie-uitwisseling), maar ook intern zijn baselines zeer nuttig. Ze brengen rust en stabiliteit in een omgeving die gekenmerkt wordt door vaak veranderende eisen bij multidisciplinaire productontwikkeling.

De ontkoppeling van verschillende dynamieken met baselines kan zeer effectief zijn. Dit is ook de basis van mijn eerdere opmerking over Word en Excel. Die kunnen met hun relatief trage veranderingstempo, een passende hartslag dicteren voor het inzetten van veranderingen in de ontwikkelingsorganisatie. Bijvoorbeeld een snel veranderende agile manier van werken met tweewekelijkse sprints en een lange doorlooptijd met driemaandelijkse updates en jaarlijkse releases.

Een sterk argument om RM-tools te gebruiken is de ondersteuning van traceerbaarheid. De meeste leveranciers van tools adverteren dat hun tool in staat is om requirements aan andere requirements te koppelen. Zoals ik al schreef in mijn column over traceerbaarheid, gebeurt dit in de praktijk niet. Het wordt zelfs ontmoedigd.

Traceerbaarheid draait om het vinden van de bron van requirements. Deze bronnen zijn ofwel een eis-analyse verklaring of een ontwerpbeslissing op een hoger niveau. Het is daarom essentieel dat de tool de mogelijkheid biedt om andere entiteiten dan requirements te creëren en ook om specifieke relaties (trace-links) te leggen tussen requirements en bijvoorbeeld ontwerpbeslissingen.

Ook hier zult u versteld staan van het aantal hulpmiddelen dat dit niet kan ondersteunen.

In de vorige column presenteerde ik het W-model als antwoord op de noodzaak om eigenschappen (zoals massa en volume) toe te wijzen aan systeemelementen. Men zou verwachten dat dit wordt ondersteund door toolsleveranciers die hun tools Product Lifecycle Management (PLM) tools noemen zoals Siemens, IBM, Dassault, Contact Software en PTC. Helaas zien de meeste van deze PLM-tools de eerste CAD-tekeningen als het begin van de levenscyclus van het product. Ik onderstreep het maar even: dit is bijna aan het einde van het ontwerpproces!

Met andere woorden: deze tools slaan de linkerbenen van het W-model (van productgeboorte tot adolescentie) volledig over. In de afgelopen jaren hebben deze PLM-toolleveranciers geprobeerd het gat op te vullen door aanbieders van model-based system engineering-tools over te nemen of interfaces aan te bieden met (Enterprise Architect, Capella, No Magic) en vervolgens de arme klant de integratie- en interfaceproblemen te laten oplossen, waarbij ze ook nog eens blijven zitten met verouderde concepten als RFLP, incompatibele terminologie, volledige afwezigheid van het concept producteigenschappen en het ontbreken van de mogelijkheid voor attributen op relaties.

Een aantal populaire requirements management tools breiden nu hun functionaliteit uit naar systems engineering, zoals Doors, Polarion, Relatics, TopTeam en Jama. Zij worden geconfronteerd met de randvoorwaarden waaraan moet worden voldaan vanuit een SE-perspectief: goed configuratie-, change- en release management, cross-context traceerbaarheid, life cycle ondersteuning voor systeemelementen, baselining en meer.

Terugkomend op ons oorspronkelijke onderwerp: ik moet nog een RM-tool zien dat niet alleen de managementaspecten, maar ook de engineeringaspecten ondersteunt. Zoals kwantificering van requirements met tags en qualifiers volgens Gilb; de relatie tussen functies en functie-eigenschappen (ook om af te komen van de achterhaalde splitsing van functionele en niet-functionele requirements); hoe eigenschap-specifieke requirements te schrijven; ondersteuning voor het waarborgen van de intrinsieke kwaliteit van requirements (functionaliteit geboden door tools als QVScribe); gemakkelijke vergelijking tussen het systeem zoals vereist, het systeem zoals ontworpen en het systeem zoals getest. Een requirement is immers meer dan een tekstuele beschrijving.

In de column over traceerbaarheid vermeldde ik dat requirements tooling kan helpen bij het beantwoorden van de vraag: waarom bestaat deze requirement en waarom heeft het deze waarde? PLM-tooling kan helpen bij het beantwoorden van vragen als ‘Als dit onderdeel in het veld faalt, kan tooling mij dan helpen bij het vinden van de systeemfunctie(s) die door dit falende onderdeel worden beïnvloed?’