Non-functional requirements voor een blije (beheer) organisatie… (Deel 2)

Projecten die worden uitgevoerd hebben baat bij goede non-functional requirements voordat de uitvoering begint en bepalen het welslagen ervan. Al is de op te leveren functionaliteit of de software nog zo goed, op tijd klaar en gestoeld op state-of-the art technologie, als de non-functional requirements niet of tendele zijn ingevuld zal de acceptatie van het nieuwe informatiesysteem vele malen minder zijn door de gebruikers en zullen beheer en onderhoud meer effort vragen.

Even terug naar de definitie zoals in onze eerste blog. 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. Het maakt daarbij niet uit of het gaat om het vernieuwen van een bestaand informatiesysteem of dat er een compleet nieuw informatiesysteem komt. Goed ingevulde randvoorwaarden maken dat de gebruiker tastbaar profijt heeft van de uitrol van dat ene informatiesysteem.

Te denken valt aan performance, beschikbaarheid, gebruiksgemak (usability) en beveiliging / beveiligbaarheid. Middels het bepalen en uitwerken van non-functional requirements kan  worden voorkomen dat wordt live gegaan met een informatiesystemen terwijl dit eigenlijk nog niet kan. Laat ik eens conreet ingaan op een aantal van deze requirements en de rol van Functioneel Beheer waarbij het niet uitsluitend gaat om het uitvoerende niveau.

Enkele  non-functional requirements

Performance

Een goede performance is van cruciaal belang voor een succesvol project en de beheerorganisatie, deze laatste kan er zelfs op worden aangesproken als het informatiesysteem eenmaal is live gezet en hieraan wordt voorbijgegaan. 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 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 te beïnvloeden performance is het advies harde requirements af te spreken. In de testfase dient hierop getoetst te worden en kan eenvoudig getest worden als  de software is opgeleverd. Uitgangspunt hierbij is de ervaring van de gebruiker. Functioneel Beheer speelt hierin een begeleidende rol bij het faciliteren van het acceptatietesten van het informatiesysteem waarin 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 de beschikbaarheid van een nieuw informatiesysteem ook belangrijk om 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 typen 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” waarin 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 dat ene requirement een weloverwogen beslissing kan nemen het risico dat daarbij hoort te accepteren of uit te stellen 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.