Marcel van der Laan is technisch consultant bij ICT Embedded. Hij adviseert en geeft trainingen op het gebied van requirementsengineering, de processen, best practices en tooling.

10 October 2009

Hergebruik in ontwikkeling van software en systemen is niet nieuw. We hebben het immers vaak over (software)componenten. Hergebruik van beschikbare en bewezen componenten scheelt veel tijd tijdens de realisatie van een product. Maar kunnen we vóór deze fase al de voordelen van hergebruik benutten? Ja, dat kan. Met een gestructureerde aanpak kunnen we de requirements voor een product eerder en beter gedefinieerd krijgen. Dit betekent dat we de juiste producten eerder en met hogere kwaliteit op de markt kunnen brengen.

Stel, je stapt een bibliotheek binnen op zoek naar een boek om in te zien. De keurige dame achter de balie zit al glimlachend op je te wachten. Je vraagt: ’Heeft u misschien een boek over Japanse vechtvissen?‘ Zij klopt wat op het toetsenbord van haar computer en zegt uiteindelijk: ’Ja, we hebben wel een boek over vissen. Het moet hier in de kasten staan, dus áls het niet is uitgeleend, dan zult u het daar vinden.‘ Achter haar doemen rijen boekenkasten op en je vraagt op welke schap het boek precies staat. ’Tja, dat durf ik niet te zeggen‘, zegt ze aarzelend. ’Iedereen die zijn boeken terugbrengt, zet het zelf ergens terug in de kast. Overigens weet ik niet of er ook iets over jachtvissen in staat.‘

Je bedankt haar vriendelijk voor haar hulp en loopt richting de kasten. Op de planken staan alle boeken door elkaar: fictie bij non-fictie, bestsellers bij klassiekers – het is een chaos. Hier ergens, tussen alle boeken, ligt de informatie waar je naar op zoek bent. Maar hoe vind je die?

Als bibliotheken op deze manier georganiseerd zouden zijn, zouden maar weinig mensen de moeite nemen om deze vorm van hergebruik toe te passen. Om efficiënt informatie uit een bibliotheek te kunnen gebruiken, moeten we de informatie gestructureerd en georganiseerd beheren en beschikbaar stellen.

Hergebruik van requirements gebeurt al wel, maar het gaat veelal ad hoc en ongestructureerd. Dit komt doordat requirements van verschillende bronnen en projecten afkomstig zijn. Ze worden eenvoudig gekopieerd en in een nieuw document geplakt. Er bestaat geen duidelijk proces of strategie achter deze vorm van hergebruik en op de kwaliteit en consistentie van de requirements krijgen we al helemaal geen garantie.

 advertorial 

Hands-on GaN Doherty amplifier design

During the Benelux RF Conference at Van der Valk Nijmegen on 1 June, Martijn Brethouwer (Bruco IC) will take you through the paces of a Doherty amplifier development process with all its pitfalls and hurdles. Take a look at the complete program. We only have a limited number of tickets left, so sign up in time.

Het zoeken naar deze herbruikbare requirements is niet makkelijk. We moeten weten waar we de informatie kunnen vinden. In een organisatie die veel producten ontwikkelt, kan dat lastig zijn. We moeten dan maar net weten waar de relevante informatie te vinden is en hopen dat het daar goed geschreven staat en op een manier dat het eenvoudig opnieuw te gebruiken is. En we kunnen niet eens de hulp inroepen van de aardige baliedame.

Niet iedere organisatie zal baat hebben bij hergebruik. Waar one-of-a-kind projecten worden gedaan in sterk verschillende domeinen, zal er te veel ongecorreleerde informatie zijn om hergebruik efficiënt toe te kunnen passen. Als een organisatie meerdere projecten in één domein uitvoert, is er wel voordeel te halen door deze domeinkennis te vangen in een bibliotheek voor toekomstig gebruik.

Door requirements te hergebruiken, staat de deur open om de daaraan gekoppelde implementatie en tests ook opnieuw in te zetten. Dat komt de ontwikkeltijd en de kwaliteit ten goede. Wat hebben we nodig om efficiënt requirements te kunnen hergebruiken? Er is een aantal belangrijke zaken waar we rekening mee moeten houden: de requirements moeten breed toepasbaar zijn, de kwaliteit moet gegarandeerd zijn en ze moeten snel en makkelijk te vinden zijn.

In dit artikel identificeer ik een aantal stappen om te komen tot een oplossing die deze punten in ogenschouw neemt (zie het kader voor een simpel uitgewerkt voorbeeld). Tooling gebruikt in deze stappen valt buiten de scope van dit artikel. Ook geldt dat niet iedere organisatie elke stap zal moeten ambiër

Orde in de chaos

Een ongeorganiseerde berg informatie is moeilijk te doorzoeken en te onderhouden. Door de informatie in een centrale plaats te beheren, zal het eenvoudiger zijn om in kaart te brengen welke informatie aanwezig is. Dit zal de vindbaarheid van de informatie vergroten.

Een centrale bibliotheek zal ook het beheer op de kwaliteit eenvoudiger maken. Maar het gebeurt niet vanzelf. We moeten binnen de organisatie een eigenaar aanstellen die deze kwaliteit waarborgt. Requirements worden pas in de bibliotheek opgenomen als ze aan de vereiste kwaliteit voldoen zoals de eigenaar die heeft bepaald.

Ook zullen organisaties moeten kijken naar hoe en wanneer ze de bibliotheek vullen. Niet alleen moeten ze de bestaande informatie opsporen, ook zullen ze nieuwe requirements van huidige en toekomstige projecten in kaart moeten brengen en opnemen in de centrale bibliotheek. Als we hier niet de tijd en de moeite voor nemen, dan zal de bibliotheek niet meegroeien met de organisatie en zal het nut ervan snel verdwijnen.

Het opzetten en beheren van de requirementsbibliotheek is het beste in handen van een projectonafhankelijk team. Uit ervaring blijkt dat het niet goed werkt om deze taken bij de individuele projecten neer te leggen. Die hebben namelijk een andere focus en prioriteitstelling, namelijk het op tijd voltooien van het product. Individuele projecten moeten we zien als de gebruikers van de bibliotheek. Tegelijkertijd zijn de projecten de bron van nieuwe informatie voor de bibliotheek.

Als de organisatie de eerste stap naar een gecentraliseerd systeem bewust heeft genomen, dan zijn de hierop volgende stappen eenvoudiger om te zetten. Ze zijn dan meer van technische aard en met weinig organisatorische aanpassingen te verwezenlijken.

Parametriseer

Door abstractie toe te voegen aan de requirements in de bibliotheek is het mogelijk de toepasbaarheid van zo‘n requirement te vergroten. Deze abstractie krijgen we door de informatie te parametriseren. Dat wil zeggen dat we concrete informatie uit de requirementtekst moeten halen en dat daar symbolische parameters voor in de plaats komen. Dit gebeurt zonder de kern van de betekenis van de requirement te wijzigen. Op het moment dat de requirement wordt hergebruikt in een project, krijgen de parameters een waarde behorend bij de eisen van dat project.

Deze methode houdt de centrale bibliotheek van herbruikbare requirements relatief compact. Requirements die sterk op elkaar lijken en waarvan alleen de details anders zijn, hoeven we nu slechts eenmaal in de bibliotheek op te nemen. Door requirements nog abstracter te maken, kunnen we komen tot een set van (boilerplate-)templaten die de basis vormen van alle requirements; dit zijn goedgekeurde zinsconstructies die globaal inzetbaar zijn.

Conceptualiseer

De eisen van producten zijn vaak in concepten in te delen, waarbij ieder concept is gespecificeerd in een aantal requirements, al dan niet met uitleg over aandachtspunten bij het gebruik van zo‘n concept. Onder softwareontwikkelaars staat dit fenomeen al langer bekend als design patterns. Bij requirements heten die dan ook requirements patterns.

Door die requirements patterns te organiseren in een bibliotheek kunnen we samenhangende requirements snel terugvinden en hergebruiken. We gaan in de bibliotheek dan ook op zoek naar deze concepten, in plaats van individuele requirements. Ieder concept kan uiteraard meerdere malen worden gebruikt bij de definitie van een specifiek product.

De concepten die in requirements patterns gevangen zitten, zijn voor een groot deel domeinspecifiek. Hoewel er al wel standaard requirements patterns zijn gedefinieerd, zal iedere organisatie toch zijn eigen concepten en patronen moeten maken die toepasbaar zijn in de eigen business.

In de praktijk

Deze drie stappen leiden tot een sterke basis om requirementshergebruik toe te passen. Al vanaf de eerste stap kunnen ontwikkelteams profiteren van de bibliotheek. De daaropvolgende stappen maken het gebruik ervan nog efficiënter en effectiever.

Bij NXP Semiconductors, Business Line Car Entertainment Solutions, heb ik een proef gedaan waarbij we een bibliotheek van geparametriseerde requirements hebben geïmplementeerd die specifiek is gericht op een functioneel domein. We hebben tooling gemaakt om gebruikers van verschillende projecten te laten zoeken in de bibliotheek en om de requirements vervolgens eenvoudig te kopiëren naar een projectspecifieke locatie. Hierbij werden de kopieën automatisch gekoppeld aan het origineel. Zo konden de projecten aanpassingen in de bibliotheek meteen signaleren en (optioneel) overnemen.

De kopieën waren deels vergrendeld om aanpassingen aan de requirementteksten te voorkomen en dus de integriteit van de kopie ten opzichte van het origineel te behouden. Kenmerken van de requirement zoals de parameterwaardes en de bron konden de projectteams wel wijzigen om de requirements projectspecifiek te maken.

Bijkomend voordeel van dit systeem was dat we naast requirements ook andere informatie konden hergebruiken, zoals (domein)terminologie en documentreferenties. Dit levert nog betere consistentie op bij verschillende projecten.

De proef is zeer goed verlopen. Hij heeft gezorgd voor een centrale kennisbank van domeingerelateerde requirements waar meerdere projecten uit hebben geput. De geïmplementeerde tooling bleek eenvoudig in gebruik en zonder ingrijpende aanpassingen aan de bestaande processen van de projecten in te voeren.

Conclusie? Hergebruik van requirements is mogelijk op verschillende manieren, van eenvoudig tot complex. Het structureren en organiseren van requirements is van groot belang voor de efficiëntie van het hergebruik. Alleen dan zal het mogelijk zijn de requirementsfase van projecten aanzienlijk te verkorten, met een snellere start van de realisatie als gevolg. Uiteindelijk zal dit leiden tot het juiste product dat eerder op de markt verschijnt.