Artikel

Pragmatisch requirements engineeren…

…en daarmee successen bereiken!

Dit artikel is deel twee in een reeks van vijf artikelen over succesvol requirements engineering. In het vorige deel hebben we gezien dat requirements een belangrijke bijdrage leveren aan het succes van een project. In het artikel is stilgestaan bij het aandachtspunt 'organiseer je proces'. Door het requirements proces goed te organiseren kan je veel knelpunten, die het succes van requirements engineering bedreigen, voorkomen. In dit artikel besteden we aandacht aan een volgend aandachtspunt, namelijk 'wees pragmatisch'.

Figuur 1: Aandachtspunten voor succesvol requirements engineering

Bij elke stap in het requirements proces staan we voor belangrijke keuzes. We willen requirements van zo hoog mogelijke kwaliteit bereiken en alle stakeholders daar optimaal bij betrekken. Dit kost tijd en tijd is in de meeste gevallen schaars.

Valori maakt gebruik van het RequireSMART® proces voor requirements engineering. Dit proces is gebaseerd op een aantal best practices en bestaat uit de volgende stappen:

  1. Voer review uit
  2. Kick off
  3. Inventariseer losse eisen
  4. Voer kwaliteitscontrole uit
  5. Schrijf het eisendocument
  6. Review het eisendocument
  7. Schrijf het evaluatierapport

Per stap in dit proces moeten we onszelf daarom afvragen hoe uitgebreid deze moet zijn en hoeveel tijd we erin willen steken. We willen onnodige starheid en traagheid voorkomen en onze doelen bereiken door een zo pragmatisch mogelijke insteek te kiezen.

Onder pragmatiek verstaan we niet het overslaan van stappen in het requirements proces. Ons uitgangspunt is dat alle stappen in het proces waarde toevoegen en daardoor niet overgeslagen kunnen worden. Wel kun je pragmatisch met deze stappen omgaan. Hoe je dit kan doen laten we later in het artikel zien bij de paragraaf ‘Pragmatiek bepalen’.

De mate van pragmatiek is sterk afhankelijk van de complexiteit van de omgeving waarin het project zich afspeelt. Onderstaand voorbeeld illustreert dit.

De tuin zomerklaar maken

Elke lente maken we onze tuin klaar voor de zomer. In dat geval kunnen we het geheel overzien en is ons gezin de enige belanghebbende. Na kort overleg pakken we dan ook meestal de snoeischaar om de planten te snoeien, we maaien het gras, planten wat plantjes en klaar is Kees. Weinig complexiteit, een pragmatische aanpak.

Toen het park in de buurt zomerklaar gemaakt moest worden was het echter een ander verhaal. Alle buurtgenoten hadden inspraak in de beplanting, plaatsing van speeltoestellen en andere voorzieningen. Na discussies over het benodigde budget in de wijkraad en gemeenteraad werd gestart met het maken van de plannen. Na de planvorming kwamen verschillende bedrijven de grond omspitten, herplanten, herbouwen, bestaande speeltoestellen schilderen etc. Na twee maanden vond er een feestelijke heropening plaats. Veel complexiteit, waardoor een minder pragmatische aanpak beter werkt. Hierdoor voldoet het park nu wel aan de wensen van de meerderheid. Dit effect was naar alle waarschijnlijkheid niet bereikt als men in deze complexe omgeving zonder de buurtgenoten te horen gewoon van start was gegaan.

Complexiteit bepalen

Om de mate van pragmatiek te kunnen bepalen dienen we dus eerst te kijken naar de complexiteit van de verandering. De complexiteit van de omgeving kun je inschatten op basis van een aantal factoren. Dit kunnen harde factoren zijn, zoals:

  • Aantal verschillende belangen: hoe meer verschillende belangen er spelen, des te complexer de omgeving is. Er dient immers met meer belangen rekening gehouden te worden. Dit kost ook meer tijd. Een belanghebbendenanalyse kan je helpen bij het verkrijgen van het inzicht in het aantal verschillende belangen en belanghebbenden.
  • Aantal geraakte onderdelen (context): hoe meer onderdelen van de informatievoorziening (organisatie, processen, functionaliteiten, systemen) geraakt worden des te complexer de omgeving is. Een enterprise architectuur kan je helpen bij het verkrijgen van het inzicht in het aantal geraakte onderdelen.
  • Grootte van de wijziging: kleine aanpassingen in de informatievoorziening zijn normaliter minder complex dan een volledig herontwerp. Hier kan een functiepuntanalyse (Langbroek, 2003) je helpen bij het verkrijgen van het inzicht in de grootte van de wijziging.

Maar het kunnen ook zachte factoren zijn, bijvoorbeeld:

  • Het bedrijfsbelang: hoe groter het belang is dat een bedrijf bij het project heeft, des te riskanter en complexer de omgeving zal zijn. Men zal bijvoorbeeld meer controle op het project willen hebben en er druk op willen uitoefenen.
  • Wie de belanghebbenden zijn: op basis van je eigen ervaringen of die van anderen met de belanghebbenden kan ingeschat worden hoe bijvoorbeeld de samenwerking tussen de mensen zal verlopen. Complex, of niet.
  • Het politieke belang: projecten waarbij politiek een grote rol speelt zullen in de regel complexer zijn dan veranderingen waarbij politiek een minder grote rol speelt.

Op basis van deze factoren in de omgeving kun je een inschatting maken van de complexiteit.

Bijvoorbeeld door elk van de factoren te scoren op een schaal van 1 tot en met 3, waarbij 1 een weinig complexe en 3 een zeer complexe omgeving is. Het gemiddelde van de scores van de factoren geeft aan wat de complexiteit van de omgeving is.

Hoe minder complex deze omgeving, des te pragmatischer de insteek kan zijn. In figuur 2 wordt de relatie tussen complexiteit en pragmatiek getoond.

Figuur 2: Relatie tussen complexiteit en pragmatiek

Pragmatiek bepalen

Als we eenmaal de complexiteit van de omgeving kennen, is het zaak om de mate van pragmatiek daarop aan te passen.

Binnen het requirements proces is er een aantal ‘knoppen’ waar je aan kunt draaien om te voorkomen dat er tijd wordt verspild aan onnodig zwaar requirements engineering (zie figuur 3).

Figuur 3: Het pragmatiek mengpaneel

Processtappen samenvoegen

In minder complexe omgevingen kun je in één sessie de requirements inventariseren (stap 3 inventariseer losse eisen), en vervolgens gelijk analyseren om conflicten te ontdekken (stap 4 voer kwaliteitscontrole uit), deze direct bespreken, beschrijven (stap 5 schrijf het eisendocument) en reviewen (stap 6 review het eisendocument). Het resultaat van een dergelijke sessie zijn dan de definitieve requirements.

In complexe omgevingen zullen er in de regel meer requirements te inventariseren zijn. Daardoor kan het lastig zijn om al deze stappen in een kort tijdsbestek uit te voeren. Plan hiervoor dan ook meer tijd in en manage de verwachting naar de opdrachtgever. Als de complexiteit veroorzaakt wordt door politiek, dan kan men bijvoorbeeld de requirements eerst willen afstemmen met de achterban, alvorens ze goed te keuren.

Bilateraal versus lateraal

Als de omgeving niet echt complex is, kun je deze aanpak bijvoorbeeld goed combineren met de laterale inventarisatie (alle stakeholders tegelijkertijd spreken), maar ook met de bilaterale inventarisatie (elke stakeholder apart spreken).

Dit zijn twee van de knoppen waaraan je kunt draaien om een pragmatischer proces te krijgen. De effecten die je met de andere twee knoppen kunt bereiken worden beschreven in het boek ‘Precies volgens Plan!’.

Goed is goed genoeg

Het pragmatisch uitvoeren van requirements engineering houdt ook in dat je weet wanneer je moet stoppen. Goed is immers goed genoeg. Maar wanneer is iets nou ‘goed genoeg’?
In de echte wereld is er maar één manier waarop je hier achter komt: vraag de belanghebbenden of de requirements voor hen voldoende duidelijk zijn om:

  • Ze te durven accorderen;
  • De project business case erop te baseren;
  • De ontwerpen voor de oplossing erop te kunnen baseren;
  • De bijbehorende oplossing erop te kunnen bouwen;
  • De acceptatiecriteria ervan af te kunnen leiden;
  • Ze te accepteren;
  • Ze in beheer te kunnen nemen.

Als de belanghebbenden alle vragen met ‘ja’ beantwoorden ben je er nog niet. Verifieer of de requirements ook daadwerkelijk goed genoeg zijn. Dit kun je doen door het stellen van kritische open vragen. Bijvoorbeeld: Waarom durf je ze te accorderen? Welke requirements dragen in positieve zin bij aan de business case? Welke acceptatiecriteria kun je afleiden?

Vraag ook meerdere belanghebbenden om uit te leggen wat een bepaalde requirement betekent. Komen ze met verschillende antwoorden, dan zijn de requirements nog niet goed genoeg. De kwaliteit dient dan verbeterd te worden.

Als de antwoorden op zowel de gesloten, als de open vragen geen reden tot twijfel meer geven, kun je ervan uitgaan dat de requirements goed genoeg zijn.

Het toetsen of de requirements goed genoeg zijn kun je al vroeg in het proces van requirements engineering toepassen. Hiermee voorkom je dat er tijd en geld verspild wordt aan requirements die al goed genoeg zijn. Mede hierdoor kom je op pragmatische wijze tot een sterk en compleet requirementsdocument.

Figuur 4: De meest voorkomende problemen bij requirements engineering

Al met al leiden deze maatregelen tot een pragmatischere insteek van requirements engineering dan in de meeste gevallen wordt geadviseerd en daarmee tot het oplossen van een deel van de in figuur 4 genoemde problemen. Welke maatregelen voor jou werken is zoals eerder aangegeven een kwestie van goed kijken naar jouw organisatie of project.

Hiermee hebben we het tweede aandachtspunt behandeld. In het volgende artikel gaan we verder met het volgende aandachtspunt voor succesvol requirements engineering: “Start met het probleem”.

 

Precies volgens Plan!

Dit artikel is gebaseerd op het boek ‘Precies volgens Plan!’ geschreven door Mark Hoogveld, Jan Willem Knop en Marcel Schaar. Eerder verscheen in dit blad het artikel: “Requirements zijn de Big Hitter…” waarin het boek wordt geïntroduceerd.

In het boek ‘Precies volgens Plan!’ (ISBN-13: 9789012583060) geven we meer concrete tips en adviezen waardoor requirements engineering succesvol uitgevoerd en geïmplementeerd kan worden in een organisatie. In iedere organisatie! En uiteindelijk is ‘succesvol’ requirements engineering vooral ook een kwestie van keuzes maken die passen bij jouw organisatie. Die keuzes maak je met al de mensen die het moeten doen. Requirements engineering is tenslotte mensenwerk.

Ben je door het lezen van dit artikel benieuwd naar de andere tips in het boek, neem dan contact op met Valori of ga naar www.valori.nl.

Categorie:   
Auteur(s)
afbeelding van markhoogveld
Mark Hoogveld
Valori Business Architects - Consultant

Mark Hoogveld is werkzaam bij Valori Business Architects als consultant. Mark heeft zich tijdens zijn carriere toegelegd op het snijvlak tussen business en IT. Ervoor zorgen dat de mogelijkheden die IT biedt optimaal afgestemd worden op de behoefte van de klant en de business. Vandaar dat hij uiteindelijk bij Valori is geland. Inmiddels heeft hij, vanuit zeer verscheidene rollen, al meer dan tien jaar ervaring in het bereiken van synergie tussen business en IT op pragmatische wijze.

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.
Indien het niet lukt om een reactie te plaatsen, stuur dan uw reactie naar redactie@xr-magazine.nl.
Alle inzendingen dienen correct, professioneel en beschaafd te zijn. IP-adressen worden gelogd, maar niet gepubliceerd. De redactie van XR Magazine behoudt zich het recht voor om anonieme reacties (niet op naam) of zonder geldig e-mailadres, te verwijderen zonder kennisgeving. Ook reacties waarin commerciële uitingen worden gedaan en/of commerciële producten en diensten worden aangeboden worden door de redactie verwijderd of ontdaan van commerciële uitingen zonder kennisgeving.