Goede non-functionele eisen zijn belangrijk voor het succes van projecten. Ze moeten vooraf goed worden vastgesteld. Zelfs als de software perfect is, op tijd klaar is en de nieuwste technologie gebruikt, kan een slecht ingevulde non-functionele eis zorgen voor minder acceptatie bij gebruikers. Dit leidt vaak tot meer werk voor beheer en onderhoud. Het is belangrijk om deze eisen goed in te vullen voor een soepel lopend project.
Non-functional requirements
We beginnen bij het opfrissen van definitie van non-functionele requirements. Zoals gegeven in het eerste deel: Niet-functionele requirements, vergeet ze niet! (Deel 1). Non-functional requirements zijn alle denkbare eisen en wensen die aan een informatiesysteem (website/applicatie, dienst of product), gesteld worden en los staan van wat de gebruiker er allemaal wel of niet mee kan. Of het nu gaat om een vernieuwd of nieuw systeem, deze eisen zijn altijd belangrijk. Goed gedefinieerde randvoorwaarden zorgen ervoor dat de gebruiker daadwerkelijk profiteert van het systeem. Ze maken het systeem bruikbaar en waardevol voor de eindgebruiker.
Voorbeelden van non-functional requirements
Non-functionele eisen zoals performance, beschikbaarheid, gebruiksgemak en beveiliging zijn belangrijk voor een goed werkend informatiesysteem. Door deze eisen vooraf goed te bepalen, kan worden voorkomen dat een systeem live gaat terwijl het eigenlijk nog niet klaar is. Functioneel Beheer speelt hierin een belangrijke rol, niet alleen op het uitvoerende niveau, maar ook bij het vertalen van deze eisen naar de praktijk.
Performance
Een goede performance is van cruciaal belang voor een succesvol project en de beheerorganisatie. De beheerorganisatie kan er zelfs op worden aangesproken als het informatiesysteem eenmaal is live gezet en er wordt voorbijgegaan aan de performance. Niet alleen de performance van de leverancier die het nieuwe informatiesysteem gaat ontwikkelen is van belang, ook de snelheid van het informatiesysteem en haar componenten zelf. Het formuleren van haalbare, goede performance requirements is erg lastig. Functioneel Beheer kan dit vertalen vanuit de gebruikerswens naar IT-oplossingen.
Technische performance wordt beïnvloed door de hele keten heen. Van de pc van de gebruiker en zijn internet verbinding tot de bedrijfsapplicatie die gegevens ontsluit (en de onderliggende hardware). Voor de beïnvloedbare performance is het advies harde requirements af te spreken. In de testfase dient hierop getoetst te worden. Ook kan er eenvoudig getest worden als de software is opgeleverd. Het uitgangspunt hierbij is de ervaring van de gebruiker.
Functioneel Beheer speelt een begeleidende rol bij het faciliteren van acceptatietesten van het informatiesysteem waarin de performance in scope wordt getrokken. Sterker nog Functioneel Beheer kan eventueel een no-go geven als dit niet in orde is. Performance degradatie herstellen na livegang is namelijk lastiger dan deze voorkomen.
Beschikbaarheid
Naast performance is het ook belangrijk de beschikbaarheid van een nieuw informatiesysteem goed te definiëren. Beschikbaarheid is de kans dat de dienst ook daadwerkelijk functioneert als een gebruiker deze op een willekeurig moment gaat gebruiken. Als de IT-keten achter een website niet boven de 98% beschikbaarheid uitkomt, stel jezelf dan de vraag of de architectuur wel in lijn ligt met het medium (internet, in de cloud, on-premise).
Vanuit tactisch oogpunt wordt dit doorgaans meegenomen via een Project Start Architectuur (PSA). Functioneel Beheer stelt als acceptatiecriterium het verkrijgen van inzicht in het applicatielandschap met al haar afhankelijkheden en koppelingen en het gebruikte datamodel. Het kan zelfs zo ver gaan dat hierdoor een informatiesysteem of een functionaliteit niet wordt uitgerold omdat de impact op de business en de IV te groot is en kan leiden tot onacceptabele beheerrisico’s die niemand wenst te nemen.
Gebruiksgemak
Het goed toegankelijk maken van een informatiesysteem zodat een gebruiker een proces kan uitvoeren is een aparte professie. Er worden tegenwoordig tal van Interaction Design Consultants en User Experience Specialisten ingevlogen om in te spelen op gebruiksgemak. Met deze non-functional kan een bijkomend voordeel worden behaald. Zoals het toegankelijk maken van het informatiesysteem voor doelgroepen met een beperking of voorzien in management informatie. Een ander voorbeeld is de snelheid waarmee bepaalde type gebruikers bepaalde informatie kunnen vinden of een (online) bestelling kunnen doen. Zo willen medewerkers van een financiële instelling graag één klantbeeld in plaats van het raadplegen van diverse informatiesystemen om dat ene beeld te verkrijgen (gemak dient de mens).
Het is een goede gewoonte om vanuit Functioneel Beheer met deze doelgroepen het gebruiksgemak te definiëren en te testen zodra het moment daar is. Het gebruik van technieken als “blind testing”, “eyeball tracking” waarbij gebruikers opdrachten krijgen en gemeten wordt hoe snel gebruikers begrijpen wat ze moeten doen in een informatiesysteem. Of “two-way mirror wall testing” (een fysieke muur waarachter een groepsdiscussie geobserveerd kan worden), kan haar vruchten afwerpen vanuit een nieuwe mindset. Met name hoe er naar informatiesystemen wordt gekeken en wat dit met de gebruikers doet. Zodat we op enig moment beslissen: yes, hiermee wil ik liever nog vandaag dan morgen aan de slag. Het levert meerwaarde op als gebruikers vanaf het begin bij het ontwerp van het systeem worden betrokken en hun reflecties worden meegenomen.
Beveiliging/beveiligbaarheid
Mijn stokpaardje en als laatste horde voor nu is beveiliging en beveiligbaarheid. Het informatiesysteem dient ten allen tijde veilig en beveiligbaar te zijn. Met name omdat kwaadwillenden in deze digitale tijd met data uit het systeem van alles kunnen doen zonder dat dit enig bedrijfsdoel dient dan alleen het bemachtigen van het goud (de data). Een precieze invulling is niet te geven omdat de ontwikkelingen steeds verder gaan en de stand der techniek zelfs dagelijks wijzigt.
Beveiliging gaat niet alleen over technische veiligheid van het informatiesysteem. Echter ook om vraagstukken als privacy, wie binnen het bedrijf rechten en rollen uitgeeft, wachtwoord policies en hoe toegang naar klanten wordt gecommuniceerd. Nog maar niet te spreken over het gebruik van geanonimiseerde testdata binnen een test- en acceptatieomgeving. Processen hieromtrent zijn minstens een zo groot risico als datalekken in het systeem en verdienen net zoveel aandacht. Wat mij betreft wordt afgedwongen dat dit requirement goed wordt ingevuld. Het niet goed op orde hebben van de beveiliging kan leiden tot nare datalekken en inbreuken op privacy die heel snel het nieuws halen en iets doen met het imago van het bedrijf waarin deze zijn opgetreden.
Laat Functioneel Beheer organiseren dat er een PEN test wordt uitgevoerd, logging kan worden ingeschakeld op de informatiesystemen. Laat hen het voortouw nemen bij het laten uitvoeren van een audit om kwetsbaarheden in de informatie- en IT voorziening op te sporen en te laten vertalen naar organisatorische en technische beheersmaatregelen.
Tot slot
Een projectmanager (althans iemand vanuit een bepaalde rol met mandaat) dient te bewaken dat aan de non-functional requirements tegemoet wordt gekomen. Bij voorkeur worden deze bij aanvang van een project kenbaar gemaakt en gedeeld met de verschillende stakeholders waaronder Functioneel Beheer. Keuzes waarom een non-functional requirement niet meegaat of niet/deels wordt ingevuld dient uitlegbaar te zijn. Op een wijze dat de stakeholder die belang heeft bij die ene requirement, een weloverwogen beslissing kan nemen of het risico dat daarbij hoort te accepteren of uit te stellen is tot alles in orde is. In de volgende afsluitende blog over non-functional requirement wordt stilgestaan bij de eisen en acceptatiecriteria die vanuit Functioneel Beheer worden gesteld aan op te leveren producten met als doel ons vak op een professionele manier te kunnen uitvoeren.
Gepubliceerd in
