Gepubliceerd op:
02 december 2022
Expert:
High Tech Institute trainer Cees Michielsen belicht een handvol trends op het gebied van system requirements engineering. Hij verzorgt meerdere keren per jaar de 2-daagse training System requirements engineering improvement voor High Tech Institute.
In elke training ter verbetering van de requirements engineering komt de vraag op: wat is de beste tool om onze requirements te beheren? Om deze vraag te beantwoorden zou je alle toeters en bellen van requirements management tools moeten kennen, inclusief de laatste updates. Tegelijkertijd heb je een goed begrip nodig van de omgeving waarin je de tool wilt gebruiken. Kortom: dit is een onmogelijke taak.
Geen stress, er moet nog een eerste onderscheid worden gemaakt. Dat kun je het beste doen op basis van het soort bedrijf waarmee je werkt. Een organisatie als ASML hoeft niet te voldoen aan internationale veiligheidsnormen, informatiebeveiliging of FDA-voorschriften. Zelfs Word of Excel is dan geschikt om alles te beheren – en verrassend genoeg lijkt dit de voorkeur te hebben.
Als het om normen en voorschriften gaat, moet de software audit trails ondersteunen. Dat betekent dat er basisfunctionaliteit moet zijn voor configuratiebeheer, zoals versiebeheer, wijzigingsbeheer en statusbeheer. Het is verbazingwekkend, maar veel requirement management tools bieden deze basisfuncties niet.
Een ander onderscheid dat gemaakt moet worden is de baseline. In zijn meest basale 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. Zo’n baseline kan worden beoordeeld, gewijzigd, goedgekeurd en vrijgegeven als een aparte entiteit in de tool. Eenmaal vrijgegeven kan de inhoud van de baseline niet meer worden gewijzigd.
'In its most basic form, a baseline is a snapshot of the requirements database, containing a subset of requirements'
In sommige industrieën, zoals de auto-industrie, is de uitwisseling van baselines tussen OEM en leveranciers een standaardprocedure (beter bekend als de Lastenheft-Pflichtenheft informatie-uitwisseling), maar ook intern is het nuttig. Ze creëren rust en stabiliteit in een omgeving die bekend staat om veranderende eisen door multidisciplinaire productontwikkeling.
Het loskoppelen van verschillende dynamieken van basislijnen kan heel effectief zijn. Dit is ook de basis van mijn eerdere opmerking over Word en Excel. Zij kunnen, met hun relatief trage tempo van verandering, een geschikte hartslag dicteren voor het initiëren van verandering in de ontwikkelorganisatie. Bijvoorbeeld een snel veranderende agile manier van werken met tweewekelijkse sprints en een lange doorlooptijd met kwartaalupdates en jaarlijkse releases.
Een sterk argument ten gunste van het gebruik van RM-tools is de ondersteuning voor traceerbaarheid. De meeste leveranciers van tools adverteren dat hun tool geschikt is om requirements te koppelen aan andere requirements. Zoals ik al schreef in mijn column over traceerbaarheid, lijkt dit in de praktijk niet te gebeuren. Het wordt zelfs ontmoedigd.
Traceerbaarheid draait om het vinden van de bron van requirements. Deze bronnen zijn ofwel een requirements analyse verklaring of een ontwerpbeslissing op een hoger niveau. Daarom is het essentieel dat de tool de mogelijkheid biedt om andere entiteiten dan requirements te creëren en in staat is om specifieke relaties (trace-links) te leggen tussen requirements en ontwerpbeslissingen bijvoorbeeld.
Nogmaals, je zult versteld staan van de hoeveelheid tools die dit niet kunnen ondersteunen.
In mijn vorige column presenteerde ik het W-model als antwoord op de behoefte om eigenschappen (zoals massa en volume) toe te kennen aan systeemelementen. Je zou verwachten dat dit ondersteund zou worden door gereedschapsleveranciers die hun tools Product Lifecycle Management (PLM) 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 zeg het maar even: dit is bijna aan het einde van het ontwikkelingsproces!
'It is essential that the tool offers the possibility to create other entities than requirements, and is able to make specific relations (trace-links) between requirements and design decisions for example'
Anders gezegd: deze tools slaan de linkerbenen van het W-model (van geboorte tot adolescentie) volledig over. In de afgelopen jaren hebben deze PLM-toolleveranciers geprobeerd het gat op te vullen door aanbieders van modelgebaseerde systems engineering-tools over te nemen of door interfaces aan te bieden (Enterprise Architect, Capella, No Magic) en vervolgens de arme klant te laten opdraaien voor de integratie- en interfaceproblemen, terwijl ze ook nog eens opgescheept zitten met verouderde concepten zoals RFLP, incompatibele terminologie, het volledig ontbreken van het concept producteigenschappen en het ontbreken van de mogelijkheid voor attributen op relaties.
Een aantal populaire requirements management tools breiden hun functionaliteiten uit naar systems engineering, zoals Doors, Polarion, Relatics, TopTeam en Jama. Ze worden geconfronteerd met de randvoorwaarden waaraan moet worden voldaan vanuit een SE-perspectief: goed configuratie-, wijzigings- en releasemanagement, cross-context traceerbaarheid, levenscyclusondersteuning voor systeemelementen, baselining en meer.
Terugkomend op ons oorspronkelijke onderwerp van de dag: Ik moet nog steeds een RM-tool zien die niet alleen de managementaspecten ondersteunt, maar ook de engineeringaspecten. Zoals de kwantificering van requirements met tags en qualifiers volgens Gilb; de relatie van functies en functie-eigenschappen (ook om af te komen van de verouderde opsplitsing van functionele en niet-functionele requirements); hoe schrijf je eigenschap-specifieke requirements; ondersteuning voor het waarborgen van de intrinsieke kwaliteit van requirements (functionaliteit geleverd door tools als QVScribe); eenvoudige vergelijking van het systeem zoals vereist, het systeem zoals ontworpen en het systeem zoals getest. Een eis is meer dan alleen een tekstuele beschrijving.
In de column over traceerbaarheid noemde 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 element in het veld faalt, kan tooling me dan helpen bij het vinden van de systeemfunctie(s) die door dit falende element worden beïnvloed?’
Cees Michielsen verzorgt de 2-daagse 'SRE' training bij High Tech Institute.
Blijf op de hoogte
Ontvang onze maandelijkse updates
