Requirementsanalyse: het einde van de informatieanalyse?

De kwaliteit van ict-toepassingen laat zich uitdrukken in de mate waarin wordt voldaan aan de eisen en verwachtingen (met een ander woord: requirements) van opdrachtgevers, gebruikers en andere direct betrokkenen. Requirements staan aan de basis van plannen voor en besluitvorming over ontwikkeling en onderhoud van systemen.

Requirementsanalyse is sterk in opkomst. Het wordt steeds belangrijker om veel aandacht aan requirements te besteden. Hiervoor zijn twee redenen aan te voeren.

De eerste is de vaststelling dat er tijdens systeemontwikkelingsprojecten veel bevindingen naar voren komen die terug te voeren zijn op kwalitatief onvoldoende requirements.

De tweede reden heeft alles te maken met het invoeren van het zogenaamde demand-supply-model in steeds meer organisaties. Hierbij kunnen requirements worden gezien als het 'contract' tussen de business (demand) en bijvoorbeeld de interne ict-organisatie (supply). Requirements worden nog belangrijker als sprake is van een externe ict-organisatie, zoals bij outsourcing en/of offshoring.

Maar wat betekent dit voor de informatieanalyse, traditioneel de eerste stap in een ontwikkeltraject? Met de opkomst van de requirementsanalyse wordt ook steeds vaker de vraag gesteld of een informatieanalyse nog wel zinvol is; doen we dan geen dingen dubbel?

Requirementsanalyse is niet het einde van de informatieanalyse!

In dit artikel tonen we aan dat requirementsanalyse en informatieanalyse wezenlijk verschillende activiteiten zijn, die elkaar vooral aanvullen in plaats van overlappen:

• requirementsanalyse en informatieanalyse hebben ieder hun eigen insteek
• requirementsanalyse is richtinggevend voor de informatieanalyse
• de informatieanalyse krijgt een vliegende start als voorafgaand een requirementsanalyse is uitgevoerd
• de informatieanalyse levert een verdieping en validatie van de requirements.

Om het beste uit zowel requirementsanalyse als informatieanalyse te halen bevelen we het volgende aan:

• voer een requirementsanalyse uit voordat begonnen wordt met de informatieanalyse;
• leg de requirements afzonderlijk vast en neem ze in beheer binnen de gebruikersorganisatie;
• beperk de informatieanalyse tot het uitdiepen van de gekozen oplossingsrichting;
• gebruik een toekomstvast requirementsmodel, dat wil zeggen gericht op het beheren van requirements van de gehele organisatie;
• verwijs in informatieanalyse en functioneel ontwerp consequent naar de requirements die daarmee worden gerealiseerd.

Requirementsanalyse samengevat

Requirementsanalyse is de naam die we gebruiken voor het traject dat leidt tot een vastgestelde set requirements (baseline). Requirements zien we daarbij als de eisen die stakeholders stellen aan een oplossing. Die oplossing hoeft daarbij niet in een geautomatiseerd systeem te liggen!

Binnen de verzameling requirements onderscheiden we verschillende typen. Het piramidemodel geeft daarvan een beeld.

Omdat requirements geen ander doel dienen dan de eisen van stakeholders helder en eenduidig te definiëren, worden ze in de taal van de stakeholder vastgelegd. Dit maakt requirements toegankelijk, ook voor groepen die minder affiniteit hebben met de producten van een ontwikkelingstraject.

 

Requirements worden op het hoogste niveau gerelateerd aan de doelstellingen van de organisatie en de bijbehorende business benefits. Door de samenhang binnen het requirementsmodel kunnen zo alle projectresultaten eenvoudig worden gerelateerd aan de oorspronkelijke business case.

Informatieanalyse: twee aanpakken

Informatieanalyse is de eerste fase in de ontwikkeling van een informatiesysteem. Het doel van de informatieanalyse is om vast te stellen of het ontwikkelen of aanpassen van dat systeem mogelijk is, en wat de consequenties zijn op allerlei gebieden (technisch, economisch, sociaal, organisatorisch, et cetera).
Om hierover een oordeel te kunnen vormen is het nodig om het informatiesysteem in grote lijnen te ontwerpen en zodanig te beschrijven dat de opdrachtgever een afgewogen beslissing kan nemen over het al dan niet (laten) realiseren hiervan.

Voor informatieanalyse onderscheiden we twee verschillende aanpakken:
• De integrale aanpak.
Vanuit het bedrijf als geheel worden zowel de huidige situatie (IST) als het toekomstbeeld (SOLL) in kaart gebracht, plus de strategie om van IST naar SOLL te komen. Dit geheel wordt vastgelegd in een (bedrijfsbreed) projectenplan, met een aantal projectdefinities. De feitelijke informatieanalyse begint dan op basis van één van deze projectdefinities.
• De partiële aanpak
In de partiële aanpak wordt een afgebakend deel van het bedrijf in beschouwing genomen. Ook kan een specifiek probleem waarvoor een oplossingsrichting moet worden gezocht, de aanleiding vormen voor de informatieanalyse. In dit geval zal eerst een analyse van het probleem en de mogelijke oplossing moeten plaatsvinden, op grond waarvan een projectdefinitie wordt opgesteld.

Dit voorbeeld gaat uit van de Watervalmethode. In andere ontwikkelmethodieken komt Informatieanalyse ook voor, maar dan in andere bewoordingen. Voorbeelden hiervan zijn: Feasibility study in DSDM en Business Modelling in RUP.

Waarin komen informatieanalyse en requirementsanalyse overeen?

Requirementsanalyse en informatieanalyse hebben belangrijke overeenkomsten.

Bij zowel informatieanalyse als requirementsanalyse staat het behalen van de bedrijfsdoelen door middel van de verschillende bedrijfsprocessen centraal. In beide gevallen wordt gekeken naar de eisen en wensen van de belanghebbenden (stakeholders) op het gebied van de informatiehuishouding.

Beide analyses worden vaak vanuit dezelfde aanleiding gestart, bijvoorbeeld in het kader van een ontwikkeltraject. Er zijn ook deels dezelfde stakeholders bij betrokken, bijvoorbeeld in de rol van opdrachtgever of proceseigenaar.

Ook de analist die de requirementsanalyse uitvoert kan dezelfde zijn die voor de informatieanalyse wordt ingezet.

In een klassieke informatieanalyse heeft de fase 'bepalen oplossingsrichting' overeenkomsten met het formuleren van requirements: hier wordt immers vanuit de doelstellingen van de klant een gewenste oplossingsrichting geformuleerd.

Waarin verschillen informatieanalyse en requirementsanalyse?

Naast overeenkomsten vertonen requirementsanalyse en informatieanalyse ook belangrijke onderlinge verschillen. Die komen voort uit hun verschillende rol: requirementsanalyse richt zich op het beschrijven van voorwaarden en uitgangspunten voor een oplossing; de informatieanalyse richt zich vooral op de oplossing zelf.

Daarom hoeft het aandachtsgebied van een requirementsanalyse niet beperkt te blijven tot één informatiesysteem - de natuurlijke afbakening van een informatieanalyse. Een requirementsanalyse kan betrekking hebben op een breed gebied, zoals een organisatieonderdeel of een verzameling bedrijfsfuncties.

Een requirementsanalyse beschrijft ook requirements die niet, of niet direct, worden gerealiseerd. Juist daarom wordt bij requirements de prioriteit vastgelegd. Een informatieanalyse kent deze gelaagdheid niet.

De lifecycle van een informatieanalyse is verbonden met de lifecycle van het informatiesysteem dat wordt beschreven. Een informatieanalyse beschrijft immers een oplossing; de daaraan ten grondslag liggende eisen en wensen worden niet expliciet bewaard. De lifecycle van requirements is juist gerelateerd aan de geldigheid van de doelstellingen van de organisatie. Die kan langer of korter zijn dan de levensduur van een informatiesysteem.

De verschijningsvorm van requirements kan nogal verschillen van die van een informatieanalyse. De informatieanalyse is typisch een product van een ontwikkeltraject. Daardoor is deze gegoten in formele structuren; er moet immers goed worden aangesloten bij de systeemontwikkelmethodiek. Requirements worden beschreven vanuit de denkwereld van de business, in de taal van de stakeholders. Dit is onafhankelijk van de gekozen ontwikkelmethodiek.

Wat voegt de informatieanalyse toe aan de requirementsanalyse?

De informatieanalyse fungeert vooral als een extra validatie van het requirementsmodel.

Door het omzetten van de requirements in formele producten ontstaan nieuwe inzichten, waardoor ontbrekende of niet SMART geformuleerde requirements naar voren komen. Dit wordt nog versterkt door het tijdens de informatieanalyse invullen van ontwerpkeuzes op punten waarvoor vooraf geen requirements zijn uitgewerkt. Al deze informatie die tijdens de informatieanalyse naar voren komt, wordt verwerkt in het requirementsmodel. De informatieanalyse werkt daardoor aanvullend en kwaliteitsverbeterend voor het requirementsmodel.

Wat voegt requirementsanalyse toe aan de informatieanalyse?

Requirementsanalyse voegt op verschillende manieren iets toe aan de informatieanalyse.

In de eerste plaats creëert requirementsanalyse heldere startvoorwaarden op het gebied van de inhoud, naast de randvoorwaarden die de architectuur stelt. Dit geeft de informatieanalyse een vliegende start, waardoor de doorlooptijd van de analyse wordt bekort. Ook blijft via de requirements altijd een helder zicht bestaan op wat vereisten zijn vanuit de business en wat ontwerpbeslissingen van de ontwikkelaar. Er kan via de requirements altijd een duidelijke relatie worden gelegd tussen ontwerp en de onderliggende business case.

Verder maken requirements een goede afweging mogelijk wanneer tijdens de informatieanalyse keuzes moeten worden gemaakt: wat moet (op dit moment) wel worden gerealiseerd en wat niet? Bij requirements zijn immers prioriteiten vastgelegd én een directe relatie met doelstellingen en hun opbrengsten.

Doordat requirements SMART worden geformuleerd is de kans groter dat de uiteindelijke oplossing die in de informatieanalyse wordt uitgewerkt, voldoet aan de verwachtingen.

Tenslotte kunnen requirements ook tijdens de informatieanalyse een toegevoegde waarde hebben bij de communicatie met de stakeholders. Zij zijn immers voor de stakeholder toegankelijker en herkenbaarder geformuleerd, waardoor een drempel voor begrip - en daardoor participatie - wordt weggenomen.

Requirementsanalyse is niet het einde van de informatieanalyse... maar het begin!

Aad Mannee
Consultant requirements bij Sogeti Nederland
Ron Sintemaartensdijk
Management consultant IA/FO bij Sogeti Nederland