Requirements & Interfaces
Inleiding
Interfaces vormen een belangrijk onderdeel in elk systeemontwikkelingtraject en worden met de steeds verdergaande integratie van systemen, alleen maar belangrijker. Daarnaast leidt de implementatie van interfaces vaak tot problemen en worden ze daarom als een risico beschouwd.
Waarom worden interfaces gebruikt als het zo vaak tot problemen leidt? En tot welke problemen kan dit leiden? Hoe kunnen de uitdagingen van de implementatie van interfaces, vooral op het gebied van requirements, goed worden gemanaged en door wie?
Dit artikel biedt een antwoord op deze vragen door de meest voorkomende problemen met interfaces te benoemen, hun oorzaken en gevolgen in kaart te brengen en handvatten aan te reiken waarmee een succesvolle implementatie wel mogelijk is.
Om tot een antwoord te komen moeten we een helder beeld zien te krijgen van het begrip interface.
Wat is een interface?
Er bestaan vele vormen en definities van interfaces. Een veelomvattende definitie is de volgende:
“Een intermediair waarmee twee systemen met elkaar communiceren”.
Bij deze definitie kan onder systeem ook een mens worden verstaan. Zo is een beeldscherm een voorbeeld van een interface tussen een computer en een gebruiker; het beeldscherm zet de digitale informatie van de computer om in een voor de gebruiker begrijpbare tekstuele of grafische vorm.
Een interface kan echter ook een intermediair zijn tussen twee informatiesystemen. In dit artikel wordt uitgegaan van deze variant. In de context van dit artikel wordt daarom de volgende definitie gehanteerd:
‘Een mechanisme dat als intermediair tussen twee systemen acteert en zodoende het ene systeem toegang biedt tot één of meerdere functionaliteiten en diensten (services) van het andere systeem’.
Het systeem dat de dienst beschikbaar stelt wordt ook wel ‘provider’ genoemd, het systeem dat van de dienst gebruikt maakt wordt ‘consumer’ genoemd.
Onderstaand wordt een voorbeeld van een dergelijke interface gegeven.
Ter illustratie maken we gebruik van de online sportwinkel “Websports”: op de website van deze webwinkel (de consumer) kunnen klanten zelf hun klantgegevens registreren. Om deze gegevens te registreren in het klantregistratiesysteem van de Back Office (de provider) wordt gebruik gemaakt van de klant interface en de service ‘Registreren klant’ (zie figuur 1).
Vaak worden de begrippen interface en service door elkaar gebruikt. Bovenstaande definitie geeft het verschil aan tussen deze begrippen: een service is een dienst van een provider die functionaliteit biedt welke door een interface beschikbaar wordt gesteld aan andere systemen
Een interface kan dus nooit los worden gezien van een service en een service niet van een interface. Zonder service biedt een interface immers geen waarde voor een consumerend systeem en vice versa.
Waarom worden interfaces gebruikt?
Er zijn verschillende redenen waarom interfaces door organisaties worden gebruikt. Een aantal belangrijke redenen zijn:
- Kostenverlaging
- Minder kans op fouten
- Snel in kunnen spelen op veranderingen
Voorbeeld kostenverlaging en minder kans op fouten:
Door het gebruik van interfaces wordt de gegevensverwerking verder geautomatiseerd en zijn hierdoor minder medewerkers benodigd.
Het eerder genoemde voorbeeld van online sportswinkel “Websports” laat zien dat het registreren van klantgegevens met behulp van een interface door de klant zelf uitgevoerd kan worden. Doordat de online sportwinkel gebruik maakt van een interface worden de gegevens die de klant invoert realtime opgeslagen in het klantregistratiesysteem. Hierdoor is voor deze activiteiten geen medewerker meer benodigd in de Back Office. De vermindering van het aantal handmatige acties leidt tot een reductie van het aantal fouten en daarmee op zijn beurt weer tot een snellere en goedkopere verwerking.
Voorbeeld snel in kunnen spelen op veranderingen:
Het ontsluiten van functionaliteit middels interfaces leidt tot hergebruik en hiermee kostenreductie. De betreffende functionaliteit hoeft tenslotte niet elke keer opnieuw te worden ontwikkeld. Bovendien stelt het hergebruik organisaties in staat nieuwe systemen sneller te implementeren en hierdoor sneller in te spelen op veranderingen in de markt.
Een voorbeeld hiervan is iDEAL. iDEAL is een betaalmethode, ontwikkeld door een aantal banken, om de betaling van online producten en –diensten gemakkelijk, betrouwbaar en veilig te maken. Klanten worden hierbij tijdens de betaling direct doorverwezen naar het internetbankierprogramma van hun eigen bank.
Door hun systemen aan te sluiten op de interface van iDEAL kunnen webwinkels hun klanten snel en makkelijk voorzien van een online betaalmethode zonder zelf een dergelijk product te hoeven ontwikkelen.
Figuur 2 illustreert het gebruik van iDEAL. Via iDEAL kunnen klanten hun bestelling direct afrekenen. Als een klant een bestelling heeft geplaatst (1) en hiervoor heeft betaald (2), krijgt de webwinkel hiervan direct bericht via email (3). De webwinkel kan dan direct overgaan tot het uitleveren van de artikelen (4).
Deze voorbeelden tonen aan dat interfaces een belangrijke rol hebben in de systeemontwikkeling. Toch leidt de implementatie van interfaces zoals eerder aangegeven vaak tot problemen. Wat gaat er dan mis en hoe komt dit?
Veel voorkomende problemen, oorzaken en gevolgen
Veel voorkomende problemen met interfaces zijn:
- Onbekende of verborgen Requirements: een voorbeeld hiervan is de eigenlijke aanroep van een interface in een stap van een Use Case terwijl deze interface niet expliciet is benoemd. Een ander voorbeeld is de output van de interface in de vorm van verschillende error meldingen waarop het systeem verschillend moet reageren. Bij de uitwerking hiervan kunnen nieuwe (onverwachte) requirements in beeld komen.
- Onduidelijke werking van de interface: als bijvoorbeeld de input en de output van de interface niet bekend zijn dan kunnen er problemen ontstaan bij het aanroepen van de interface en bij het correct verwerken van het resultaat van de interface.
- De werking van de interface is niet volgens specificatie: een onjuiste specificatie van de interface zal bijna altijd leiden tot een onjuiste implementatie.
Veelal worden deze problemen veroorzaakt doordat niet alle interfaces zijn geïdentificeerd of door incorrecte, onvolledige of zelfs ontbrekende documentatie.
Dit kan tot vervelende gevolgen leiden zoals:
- Onvoorziene vergroting van de scope: wanneer tijdens de realisatie blijkt dat er additionele interfaces benodigd zijn kan de scope van het project onvoorzien groter worden. De scope vergroting kan bijvoorbeeld worden veroorzaakt doordat nieuwe services moeten worden gebouwd om te communiceren met de gevonden interface.
- Rework van reeds gebouwde functionaliteit: wanneer tijdens de testfase blijkt dat de interface niet werkt zoals verwacht, zal dit deel opnieuw gebouwd moeten worden.
- Vertraging tijdens de ontwikkelfase: ontwikkelaars moeten wachten tot de requirements van de interface helder zijn of gaan zelf uitzoeken hoe de interface zou moeten werken.
Al deze gevolgen kunnen van grote invloed zijn op de planning en het budget van het project.
De oplossing
Onderstaand hebben we een verzameling van best practices neergezet om de bovengenoemde oorzaken eerder te tackelen waardoor een groot deel van deze problemen voorkomen kunnen worden.
Onderkennen van interfaces als requirements
Ondanks het feit dat tegenwoordig veel systemen gebruik maken van interfaces onderkennen veel ontwikkelmethodieken, zoals RUP, interfaces niet expliciet als requirements. Zo biedt RUP geen best practices en templates & guidelines voor het beschrijven van interfaces. Door de services die een interface biedt te onderkennen als een requirementstype zullen de hieronder beschreven activiteiten ook voor interfaces een onderdeel van het gebruikelijke requirements management proces worden.
Expertise binnen het project
Het is dus belangrijk dat de juiste expertise aanwezig is binnen het project, in dit geval op het gebied van requirements management. Een voorbeeld hiervan is de rol System Analyst binnen de RUP systeemontwikkelmethode.
Deze persoon is verantwoordelijk voor het identificeren van alle requirements voor het te realiseren systeem. Wanneer interfaces ook als type requirement zouden worden erkend, dan zou het identificeren van de interfaces ook onder de verantwoordelijkheid van deze persoon vallen.
Afbakenen scope
Net als voor de andere requirementstypen, is het van belang in een vroeg stadium inzicht te krijgen in de interfaces van het systeem. Dit kunnen zowel interfaces zijn waarvan het systeem gebruik zal maken als interfaces die het systeem aan zal bieden. Door de interfaces expliciet te benoemen en te controleren in hoeverre er specificaties zijn en wat de kwaliteit hiervan is, kunnen eventuele verrassingen later in het traject worden voorkomen.
Beschrijven interface requirements
De exacte werking van de service achter de interface is voor de consumer altijd een blackbox. Voor de consumer is het niet noodzakelijk precies te weten hoe de service zijn werk doet. Wel is het belangrijk om te weten wat exact de services zijn die een interface biedt, hoe deze services aan kunnen worden geroepen en wat de input en output is. Een goede beschrijving van deze informatie is essentieel en wordt vastgelegd in een Service Definition document.
Daarnaast is het van belang vast te leggen hoe het consumerende systeem de gegevens moet aanleveren aan de service en hoe het systeem de ontvangen gegevens dient te interpreteren en te gebruiken. Deze gegevens worden vastgelegd in een Service Mapping document.
Traceability van en naar interfaces
Nu de interfaces als requirements type zijn geïdentificeerd kunnen ze worden opgenomen in het traceability overzicht.
Het tracen van interfaces is aan te raden omdat hiermee zowel de herkomst als het gebruik van de interface in andere requirements, zoals Use Cases, wordt vastgelegd.
Hiermee blijft het uiteindelijke doel van het gebruik van de interface duidelijk en kan de impact van eventuele wijzigingen in de interface snel op waarde worden geschat.
Een ander voordeel van de trace relatie tussen interfaces en Use Cases is dat de relatie inzicht biedt in de complexiteit van een Use Case. Het onderkennen van interfaces is dus niet alleen waardevol voor het afbakenen van de scope maar ook om een beeld te krijgen van de omvang van het systeem.
Requirements Framework
Requirements specialisten van Capgemini hebben een framework opgezet voor Requirements management, IRMA (Integrated Requirements Management Approach). Dit framework ondersteunt de bovenstaande best practices met een complete set templates & guidelines voor alle requirements deliverables waaronder ook templates & guidelines voor het beschrijven van de interface requirements.
Door gebruik te maken van deze best practices, templates & guidelines is het mogelijk om de risico’s met betrekking tot het gebruik van interfaces aanzienlijk te verminderen.
Conclusie
Wanneer we bovenstaande lezen, zien we dat het vooral belangrijk is om interfaces te onderkennen als een apart type requirement. Het onderkennen van interfaces als type requirement heeft als resultaat dat interfaces al in een vroeg stadium in kaart worden gebracht, dat ze worden opgenomen in de scope van het project en dat er afspraken dienen te worden gemaakt over de specificatie van de interfaces. Daarnaast worden interfaces opgenomen in het traceability overzicht wat bijdraagt aan een verbeterd inzicht in de complexiteit en de omvang het te realiseren systeem.
Het lijkt voor de hand liggend, toch worden interfaces vaak vergeten en zijn daarmee het ondergeschoven kindje van een project.
Het toepassen van een requirements framework binnen de gekozen ontwikkelmethode geeft een goede basis om een project tot een succes te maken. Wanneer deze ontwikkelmethode interfaces niet onderkent als requirements, is het belangrijk het framework uit te breiden zodat het ook interfaces ondersteund.. Zo’n uitbreiding is onmisbaar voor projecten waarbij gebruik gemaakt wordt van interfaces.
Een succesvol project begint met goede en volledige requirements.
Bron: Interface quote.