Requirements staan aan de basis van succes

Leuk, een nieuw ICT-systeem … Je staat aan het begin van een nieuw ICT-project. Dat er een nieuw systeem moet komen is duidelijk. Maar minder duidelijk is wat het systeem precies moet kunnen. Dit artikel geeft een overzicht (checklist) van de soorten requirements en hoe je eraan komt.

Je start een vooronderzoek om erachter te komen wat het nieuwe systeem moet kunnen. Het blijkt echter lastig. Hoe meer mensen je spreekt, hoe meer meningen je krijgt. Veel gebruikers van het bestaande systeem zijn aan dit systeem best gehecht. Zij stellen dat het nieuwe systeem ten minste de oude functionaliteit moet hebben, maar dan ook …. Er zijn ook gebruikers die helemaal niet zo tevreden zijn over het oude systeem. Zij pleiten ervoor om ….

Je praat met verschillende leveranciers. Van hen krijg je eveneens een diversiteit aan adviezen. De meeste leveranciers promoten hun eigen pakket. Sommige klinken veelbelovend. Maar duidelijk is wel dat de pakketten behoorlijk anders werken dan het bestaande systeem en dat er nogal wat veranderingen moeten gaan plaatsvinden. Ook praat je met een maatwerkleverancier. Je legt de situatie uit. Het gesprek komt al snel op de nieuwe aanpak die de maatwerkleverancier hanteert, Agile.

Het komt erop neer dat er een intensieve samenwerking tussen het ontwikkelteam en de business georganiseerd wordt. Alle eisen aan het systeem worden niet uitputtend vooraf vastgesteld, maar tijdens het ontwikkelen. Elke vier weken wordt er werkende software opgeleverd. Je kunt al snel werken met het nieuwe systeem en heel gemakkelijk nieuwe eisen inbrengen, zodat aan het einde van het project een nieuw systeem is gerealiseerd, dat volledig aan jouw eisen voldoet en waarvoor je je business niet hoeft aan te passen.

Wat is nu wijsheid? De kosten spelen natuurlijk een rol en het zou ook prettig zijn iets te kopen dat z’n waarde in de praktijk al bewezen heeft. Zo’n uniek bedrijf ben je nou ook weer niet, dat er per se iets nieuws gemaakt moet worden. Wat in ieder geval duidelijk is geworden na alle gesprekken, is dat het nieuwe ICT-systeem niet zomaar aangeschaft kan worden. Sterker nog, het is nog lang niet gemakkelijk om vast te stellen aan welke eisen het nieuwe systeem moet gaan voldoen.

Aan welke eisen moet het nieuwe ICT-systeem gaan voldoen?

Er worden nogal wat verschillende termen gebezigd, om aan te geven waaraan een ICT-systeem moet voldoen. Veel gebruikte zijn: eisen, functionaliteiten, specificaties en requirements. Het document waarin de eisen worden verwoord, kan zijn een vooronderzoeksrapport, een definitiestudie, een business case, een programma van eisen enzovoort.

Business requirements

Business requirements (ook wel needs of business doelen genoemd) zijn de verbeteringen die de business wil realiseren in een nieuw of bestaand proces, bijvoorbeeld:

meer winst
hogere omzet
grote marktaandeel
lagere kosten
hogere efficiëntie
sneller inwerktijd
minder doorlooptijd
minder risico’s
hogere tevredenheid van klanten

En dat natuurlijk uitgedrukt in normtijden of percentage en specifiek gemaakt.
Nogal eens wordt volstaan met de eisen waaraan het systeem moet voldoen, zonder expliciet te maken waarom het ICT-systeem nu eigenlijk nodig is. Business requirements zijn belangrijk omdat hiermee:

het nieuwe systeem wordt afgebakend;
een gemeenschappelijk beeld wordt gedefinieerd wat het systeem (uiteindelijk) moet kunnen. Het is nu eenmaal onmogelijk om een systeem van te voren uitputtend te definiëren. Zonder een gemeenschappelijk beeld van de business requirements kunnen (onbewust) gemakkelijk interpretaties worden gedaan die leiden tot onnodige of verkeerde uitwerkingen;
aan het einde van het project vastgesteld kan worden of het systeem goed werkt en de business doelen gehaald zijn.

Procesrequirements

Procesrequirements (ook wel user requirements, gebruiks- of gebruikerseisen genoemd) zijn de activiteiten of processen die de gebruikers met het ICT-systeem gaan uitvoeren. Hiervoor wordt nogal eens de techniek van use cases (onderdeel van UML) gebruikt.
Als input voor de procesrequirements kunnen bestaande of nieuw gemaakte procesbeschrijvingen gebruikt worden. Het lastige van procesrequirements is het detailleringniveau (granulariteit). Ze moeten niet te globaal, maar ook niet te gedetailleerd zijn. Meestal worden in een procesbeschrijving, als onderdeel van de Administratieve Organisatie of het kwaliteitsmanagementsysteem de processtappen (of activiteiten) op een wat hoger abstractieniveau beschreven. Procesrequirements die op een hoger abstractieniveau zijn gedefinieerd impliceren meer keuzevrijheid voor de selectie (pakket) of het ontwerp (maatwerk) van een nieuw systeem, maar houden ook een risico in, omdat er mogelijk belangrijke informatie over het bedrijfsproces of de gewenste werkwijze ontbreekt.

Systeemrequirements

Systeemrequirements (ook wel functional, software, solution of product requirements genoemd) zijn de acties die het ICT-systeem uitvoert ten behoeve van een gebruiker van het systeem. Ook bij systeemrequirements is het detailleringsniveau van belang.
“Het systeem moet het service proces ondersteunen” is bijvoorbeeld te globaal. De systeemrequirements worden vaak gerelateerd aan de procesrequirements en als onderdeel van de use cases gedocumenteerd.

Niet-functionele requirements

De niet-functionele requirements zijn de kwaliteitseisen waaraan het systeem moet voldoen of anders gezegd, ze geven aan hoe goed het systeem aan de functionele eisen moet voldoen. ISO 9126 geeft een overzicht van de verschillende categorieën kwaliteitseisen en kan heel goed als checklist worden gebruikt. Uiteraard zijn niet in alle gevallen alle eisen van belang. Voor elke situatie kan een andere subset belangrijk zijn. Soms is snelheid (performance) erg belangrijk, in andere gevallen kan de vertrouwelijkheid van de informatie cruciaal zijn. Per geval moet bekeken worden welke niet ‘non functionals’ ertoe doen.

Eisen met betrekking tot de transitie

Het huidige proces gaat veranderen. Aan die transitie worden eisen gesteld.

Zo worden onder meer eisen gesteld aan de gegevens die besloten zijn in het oude systeem.

Moet het oude systeem beschikbaar blijven? En zo ja, hoe lang?
Moeten de data geconverteerd worden naar het nieuwe systeem?
Moet dit geautomatiseerd gebeuren?
En hoe wordt gecontroleerd of de oude data benaderbaar zijn in het nieuwe systeem en juist worden weergegeven?

Andere transitie eisen kunnen zijn: maximale doorlooptijd van het transitietraject, opleiding en coaching van nieuwe gebruikers, beschikbaarheid van medewerkers.

Eisen met betrekking tot de leverancier

Vragen die moeten worden beantwoord zijn:

Is de leverancier betrouwbaar?
Kan de leverancier aantonen dat hij kwaliteit levert?
Heeft hij een aantoonbare staat van dienst in uw branche?
Welke nazorg wordt geboden?
Wordt ondersteuning geboden in de vorm van een helpdesk?
Welke garanties worden gegeven als de leverancier failliet gaat?

Enzovoort.

Eisen met betrekking tot de kosten

Wat mag het nieuwe ICT systeem maximaal kosten in termen van geld en inspanning van medewerkers?

Eisen met betrekking tot de werkwijze

Welke eisen moeten worden gesteld aan de selectie, ontwikkeling en implementatie van het nieuwe systeem? Welke documentatie moet minimaal worden opgeleverd?

Eisen met betrekking tot de techniek

Een nieuw systeem moet passen binnen de reeds aanwezig systemen en moet geïnstalleerd kunnen worden op de bestaande infrastructuur.

De eisen waaraan het systeem moet voldoen zijn niet alle even belangrijk. Het is een goed gebruik om deze te prioriteren met behulp van MoSCoW: Must have, Shoud have, Could have en Would have.

Hoe kom je aan al die requirements?

Meestal zijn bij de start van een ICT-project diverse informatiebronnen beschikbaar. Denk aan enterprise-, informatie- en ICT-architecturen, informatie- en ICT-beleid, kwaliteitsmanagementsysteem, procesbeschrijvingen, vooronderzoeken, definitiestudie en analyses.
Verder is het belangrijk alle stakeholders (belanghebbenden) van het ICT-systeem in kaart te brengen. Elke stakeholder heeft een belang en zal eisen stellen aan het ICT-systeem. Denk bij stakeholders aan: gebruikers, managers, ICT-manager, helpdeskmedewerkers, personeelszaken, applicatiebeheerder, technische beheerder, controller, toezichthouders, commercieel medewerkers en klanten.

Gebruikelijke manieren om de requirements te inventariseren, te analyseren en te specificeren zijn het interviewen van stakeholders, het houden van workshops, het observeren, het maken van modellen (van bij voorbeeld use cases). In gevallen waarbij het lastig is om een gemeenschappelijk beeld van de gewenste situatie te creëren kan het nuttig zijn een prototype te maken. Een prototype kan op papier of softwarematig (schermlayouts) gemaakt worden. Als de requirements opgesteld zijn, is het belangrijk om deze te laten toetsen op volledigheid en juistheid. Meestal gebeurt dit door het organiseren van een review of door het doorspreken van de requirements in bijvoorbeeld een workshop.

Moet je al die requirements van tevoren bedenken?

Of je alle requirements van tevoren moet bedenken, hangt er maar vanaf. Soms wel, soms niet. Bedenk dat onjuiste en onvolledige requirements een belangrijke oorzaak zijn van het mislukken van ICT-projecten. Anderzijds, requirements opstellen kan veel tijd kosten en het is feitelijk onmogelijk om requirements gedetailleerd, volledig en ondubbelzinnig op te schrijven. Feit is dat veel stakeholders zich de nieuwe situatie onvoldoende kunnen voorstellen en niet in staat zijn exact aan te geven waar het nieuwe systeem aan moet voldoen. Het komt heel vaak voor dat gaandeweg het project nieuwe inzichten ontstaan. Dit is aanleiding geweest voor nieuwe aanpakken om software te ontwikkelen: iteratieve aanpakken waarbij de software in iteraties van bijvoorbeeld zes weken wordt ontwikkeld en de agile-aanpak waarbij een gebruikersvertegenwoordiging participeert in het ontwikkelteam.

Wat je moet doen is het volgende. Je stelt eerst de business requirements op en wordt het hier binnen jouw organisatie over eens. Als tweede stel je globaal de overige requirements op. Je beperkt je tot de belangrijkste functionele en niet-functionele eisen. Op basis hiervan voer je een marktverkenning uit. Hulp nodig? Neem contact met ons op.