Amuses DREAM16

Dutch Requirements Engineering And ManagementDREAMagazineWWW.DREAMEVENT.NL

OKTOBER 2016

. .

Sjir Nijssen overduurzame architectuur

Willemien Brand over visual thinkingGarm Lucassen over requirements "engineering"

Nicole de Swart over werken in een hybride omgeving

DREAMagazine OKTOBER 20162

VoorwoordRedactioneel

ColofonDREAMagazine is een tijdschrift over Requirements Engineering. Het wil een platform zijn voor het uitwisselen en uitwerken van ideeënover het vakgebied.DREAMagazine verschijnt driemaal per jaar. Dit is nummer 12. Deze en de andere edities zijn te vinden op www.dreamevent.nl.Reacties en bijdragen kunnen gestuurd worden naar dreamagazine@dreamevent.nl.Redactie: Linda Haak ­ van der Spek, Reinoud de Leve, Johan Oldenziel en Hans Siebering.Deze editie is tot stand gekomen dankzij bijdragen van: Willemien Brand, Garm Lucassen, Sjir Nijssen, Priya Soekhai, Frank Steeneken enNicole de Swart.

Dit DREAMagazine is opgemaakt met Scribus 1.4.4 Open Source Desktop Publishing.

Amuses Dream 2016

We staan aan de vooravond van het DREAM event van 2016. Met dit magazine geven we jullie alvast een paar

kleine hapjes om al een beetje in de sfeer te komen. Kleine hapjes, want we hebben ons deze keer weten te

matigen. Het magazine heeft aanmerkelijk veel minder pagina’s dan de vorige nummers. “Het moet dunner” was

één van de geluiden die we van onze critici te horen kregen. Minder en kruidiger.

Met interviews en artikelen van Sjir Nijssen over wendbare, duurzame specificaties, WillemienBrand over de kracht van tekenen, Garm Lucassen over de noodzaak van goederequirements, Nicole de Swart over agile werken in een niet volledig agile omgeving,

Frank Steeneken over generieke bedrijfsmodellen en Priya Soekhai over omdenken hebben

we een plateau met een aantal zeer uitgesproken smaken voor jullie bij elkaar gebracht.

We hopen dat jullie ervan zullen genieten. “Amusez Vous”.

DREAM16 vindt plaats op 6 oktober 2016in Hotel Van Der Valk in Vianen

Het thema is:“Express Yourself! Visualisatie en modellering in Business Analyse

en Requirements Engineering”

Amuses DREAM16 3

Inhoud2 Redactioneel

Voorwoord4 Interview met Willemien Brand

Geen praatjes, maar pláátjesReinoud de Leve

8 Interview met Sjir NijssenEen referentiemodel van het NederlandsrechtReinoud de Leve & Hans Siebering

12 Hybride omgevingAgile requirements binnen debeperkingen van een hybride omgevingNicole de Swart

15 Interview met Priya SoekhaiOmdenkenHans Siebering & Reinoud de Leve

18 Requirements "engineering"?Voortschrijdend inzichtGarm Lucassen

23 Interview met Frank SteenekenSysteembenadering van terreinbeheerJohan Oldenziel & Linda Haak ­ van der Spek

26 VersusIk gebruik UML in mijn werkLinda Haak ­ van der Spek

DREAMagazine OKTOBER 20164

Hidden links: de betekenis ‘beyond thewords’“Misschien kan ik het beste beginnen met te vertellenwat er gebeurt als we visueel met elkaar gaan commu­niceren.” begint Willemien Brand. “Stel dat we het gaanhebben over de zon” Ze schrijft het woord ‘zon’ op eenvel papier. “In plaats van het woord op te schrijven, kanik ook beginnen met een zon te tekenen.” Ze tekent eenzonnetje onder het woord. “Vervolgens kan ikaan iedereen vragen wat ze zien.”

Het blijkt dat mensen dan veel eerder naast ‘zon’ ookdingen noemen als ‘warmte’, ‘zomer’, ‘droogte’, ‘vakantie’

en ‘inpakstress’. De verschillende associaties diemensen hebben bij de zon. We noemen dat de hiddenlinks. De betekenis beyond the words.Soms verlaten mensen een bespreking en denken dat zehet met elkaar over hetzelfde hebben gehad, maar blijktdat helemaal niet zo te zijn. Ze hebben heel verschil­lende associaties bij de gebruikte begrippen. Door metbeeld te werken worden die associaties veel eerderzichtbaar.Daar kun je handig gebruik van maken. In plaats van eenklant heel veel vragen te stellen naar zijn wensen enbehoeften, kun je de klant laten reageren op een beeld ofbeelden. Je schakelt dan over van ‘zenden’ naar‘ontvangen’. Hierdoor krijg je veel directer de informatiedie voor de klant belangrijk is. Je leidt de klant niet meeraf met vragen waar je vaak toch maar onvolledigantwoord op krijgt.

Tekenen = Sneller, effectiever en meerempathisch“Wij tekenen vaak de volgende driehoek: de geschreventekst, het gesproken woord en het getekende beeld. Alledrie zijn middelen om met elkaar te communiceren. Wijgeloven dat je door een plaatje te tekenen veel beter eneffectiever kunt communiceren en dat je mensen ookveel gemakkelijker mee krijgt.” Tekenen is alleen al beteromdat ons brein beelden 60.000 keer sneller verwerktdan woorden. Maar er gebeurt veel meer als je begint tetekenen.

Geen praatjes, maarpláátjes

Buro Brand is gevestigd op de begane grond van een oud kantoor­gebouw in Den Haag. De ruimte straalt een plezierige, artistieke sfeeruit. In een hoek hangen portretten van Amy Winehouse en van een kleinjongetje. “Aan schilderen kom ik de laatste tijd te weinig toe” verteltWillemien Brand. “We geven op dit moment veel trainingen en ik ben ergdruk met ons boek.” In maart 2017 verschijnt haar boek VISUALTHINKING. Willemien Brand is creative director van Buro Brand. Zijgeeft trainingen en begeleidt sessies in zakelijk tekenen en visualthinking.

Visual Thinking

door Reinoud de Leve

Amuses DREAM16 5

Door te tekenen, ga jeautomatisch jegedachten ordenen.Patronen en verbandenworden zichtbaar. Je gaatde com­plexewerkelijkheid weergeven ineen soort van Jip­en­Janneke­taal.Tekeningen helpen erg goedom complexe materie tesimplificeren. “Als ik metvrienden uit eten ga, heb ikaltijd mijn stiften bij me. Jehebt toch vaak in restaurantsvan die papieren tafelkleden.Als iemand mij iets overbijvoorbeeld pensioenen wiluitleggen, laat ik hem hetgewoon tekenen. Je krijgtdan heel andere gesprekken.Een onderwerp alspensioenen kun je volgensmij niet eens uitleggen zonder het te tekenen.”Als je tekent is het ook veel makkelijker om de aandachtvan je publiek vast te houden. Door te tekenen toon jedat je lef hebt. Je geeft iets van jezelf. Je eigen print. Eentekening is vaak een soort cadeautje. Daarmee verhoogje je X­factor. Mensen zullen graag met je willensamenwerken en je ook meer gunnen.

Meer plaatjes => minder praatjesWe praten vaak al in metaforen. We vergelijken eenproject met een weg die we moeten afleggen naar eenconcreet doel. En een andere keer zien we het project

als een kar die we metelkaar in beweging moetenhouden.

Als we al een beeld­metafoor gebruiken, is hetwel zo handig om dezedan ook te tekenen. Eentekening is een prachtigmedium om van alles aanop te hangen. Als hetproject een weg is, zullenwe waarschijnlijk onderwegwel obstakels tegenkomen.We kunnen dan eenroodwit gestreept hekje opde weg tekenen. Op eenaparte flap kunnen wevervolgens inven­tariserenwelke obstakels weonderweg denken tegen tekomen. Zo kunnen welangzamerhand het hele

verhaal inkleuren. Dat is wat wij verstaan onder visualstory telling.

Het grote voordeel van een getekende beeldmetafoor isdat je veel sneller kunt teruggrijpen op waar je in eenvorige sessie bent gebleven. Je hoeft alleen maar deweg, de boom of de kar te tekenen en iedereen herinnertzich weer de plaats, de tijd, de context en de toedracht.Zonder een plaatje heb je vaak heel veel meer woordennodig voordat iedereen weer helemaal is aangehaakt.Meer plaatjes zorgen dus voor minder praatjes en dat iswel zo snel.

Interview met Willemien Brand

DREAMagazine OKTOBER 20166

Zakelijk tekenen <> tekenen als een Picasso“Het grootste obstakel waar we telkens weer tegenaanlopen, is dat iedereen van zichzelf vindt dat hij nietkan tekenen.We besteden in onze training veel aandacht om dieverkeerde mindset weg te nemen.” Je hoeft beslist geenPicasso te zijn om zakelijk te tekenen. In de trainingleren cursisten eerst een beeldtaal op basis van simpelevormen. Willemien laat zien hoe je op een heel simpelemanier een scrum team met een Product Owner en eenScrummaster tekent. Bij zakelijk tekenen gaat het omzoveel mogelijk effect te bereiken met zo min mogelijklijnen. Een eenvoudige beeldtaal kan iedereen lerentekenen. Het kost misschien wat extra tijd om het netjeste doen, maar dat geldt ook voor het schrijven van eentekst.

Grijs = Hiërarchie“Ik zou zo graag willen dat jullie voortaan altijd beginnente tekenen met grijs. Nu maken jullie vaak dit soorttekening.” Ze begint met een zwarte stift een aantalblokken met pijlen er tussen te tekenen. Tijdens debijeenkomst, als de tekening wordt gemaakt, is het nogwel duidelijk wat er met de tekening wordt bedoeld.Achteraf is het alleen nog maar een grote wirwar vanlijnen en blokken. De tekening nodigt ook niet uit. Hettoont geen informatie. Dat wordt anders als je begint metgrijs.

Als je eerst alles in grijs tekent envervolgens met zwart accentueertwat belangrijk is en hetallerbelangrijkste nog een kleurtjegeeft, creëer je hiërarchie in jetekening. Dat maakt je tekeningveel uitnodigender. De boodschapis ook veel beter zichtbaar. Je kunthet beste pas beginnen metaccentueren wanneer je samenvatwat er is besproken. Je benadruktdan meteen in de samenvattingwat echt belangrijk is.

Visual thinking & Visualstory telling“Ik wil mensen graag middelengeven waarmee ze zelf met huneigen creativiteit aan de slagkunnen gaan. Ik geef wel eenaantal voorbeelden vanbeeldmetaforen die je kuntgebruiken in een specifiekesetting, zoals een boom, een wegof een ijsberg. Ik wil alleen nietvoorschrijven dat je in eenbepaalde setting altijd een boomof een weg moet gebruiken. Ikraad wel aan om niet te complexemetaforen te kiezen.” Visualthinking en visual story telling iseen iteratief proces. Je begint met

begrijpen. Als je met elkaar een goed begrip hebt van desetting, kun je een beeldmetafoor kiezen. Daarna vul jede beeldmetafoor verder in. Dan ben je al beland invisual story telling. Bij een weg teken je bijvoorbeeldobstakels en verkeersborden die laten zien welke routeer is gekozen en welke alternatieve routes niet. Je kuntactionborden op de weg tekenen om acties aan te geven.

Visual Thinking

Amuses DREAM16 7

Buro BRANDBuro BRAND is leidend in het incorporeren vanbeeld als communicatiemiddel in de zakelijkewereld. Managers en medewerkers overspoelenelkaar met tekst, terwijl een beeld of een tekeningzoveel meer kan zeggen, elkaar verbindt en elkaarraakt. Buro BRAND leert iedereen in zijn zakelijkeomgeving beeld te (durven) gebruiken.Ook helpen wij met onze verbeeldingskrachtbedrijven, organisaties en hun mensen omopvallender, levendiger en herkenbaarder tecommuniceren met hun doelgroepen. U kunt bij onsterecht voor uw huisstijl uitingen, zoals websites enbrochures, en natuurlijk infographics en animaties.

Zakelijk Tekenen | Business DrawingVisualiseren zorgt ervoor dat je beter luistert naarelkaar, verwachtingen onderling afstemt en demissie/visie in een snelle pitch op papier kuntkrijgen. Overleggen in scrum­sessies, agile envooral sneller samenwerken? Doe dat met eigengemaakte visuals!De training wordt standaard gegeven in deinspirerende locatie van Buro BRAND in Den Haag.Maar kan ook op locatie (nabij of bij uw bedrijf)worden georganiseerd.Voor groepen van 8­12 personen, in 4 uur (1dagdeel).

Willemien BrandWillemien studeerdeCum Laude af aan deDesign Academywaarna ze 10 jaar voorATAG werkte voordatze Buro BRANDstartte. In die tijd wonzij verschillende ‘GoedIndustrieel Ontwerp­erkenningen’ en eenRed DOT award.Willemien is ontwerper,kunstschilder envisueel facilitator enwoont met haar man,zoons en teckel Ollie inVoorburg.

Details over de obstakels, de gekozen route, of de actieskun je verder uitwerken op aparte flappen. Daarbij kun jeook schrijven. Dat is dan minder belangrijk, omdat je hetal toegankelijk hebt gemaakt. Dit proces herhaal je eenaantal keren totdat je een min of meer volledig beeldhebt.

Na anderhalf uur praten ligt er een aardig stapeltjetekeningen op tafel van onderwerpen die we hebbenbesproken. “Dat komt allemaal in het boek” zegt ze meteen lachje terwijl ze de tekeningen voor mij oprolt. Hetboek van Willemien Brand verschijnt in maart 2017 onderde titel VISUAL THINKING, Empowering people andorganisations through visual collaboration.

Interview met Willemien Brand

DREAMagazine OKTOBER 20168

Interview

In de jaren 70 verwierf Nijssen bekendheid alsgrondlegger van de modelleermethode NIAM(Natuurlijke taal Informatie Analyse Methode). NIAMonderscheidde zich van andere modelleermethodendoordat NIAM volledig was gebaseerd op feitenuitgedrukt in natuurlijke taal. De taal die de gebruikersvan software systemen gebruiken om zich te uiten.“Davy Klaassen speelt in het voetbalseizoen 2016­2017 voor Ajax” is een voorbeeld van zo’n feit. Door teabstraheren over dit feit kunnen we volgens de methodehet volgende feittype afleiden: “<voetbalspeler> speelt(speelde) in het voetbalseizoen <voetbalseizoen> voor<voetbalclub>.” Dit feittype vertelt ons iets over welkeentiteiten (voetbalspeler, voetbalseizoen, voetbalclub) weonderscheiden en welke relatie er tussen deze entiteitenbestaat. Feittypen vormen ook een soort ‘grammatica’voor concrete feiten. “Louis van Gaal speelde in hetvoetbalseizoen 1980­1981 voor Sparta.” is een andervoorbeeld van zo’n feit, dat voldoet aan het patroon vanhetzelfde feittype.

Later ontwikkelde Nijssen met PNA de methodecogNIAM (Cognition enhanced NIAM). CogNIAM bouwtvoort op de ideeën uit NIAM en is net als NIAMgebaseerd op feiten uitgedrukt in natuurlijke taal. Het iseen methode om de context en samenhang van kennisbinnen een organisatie of tussen organisaties helder temaken alsmede de communicatie tussen deverschillende partijen. CogNIAM onderscheidt drieniveaus van kennis. Op het laagste niveau heb je de(concrete) feiten. Op het tussenliggende niveau heb jedomeinspecifieke kennis. Het feittype zoals hierbovenbeschreven is onderdeel van de domeinspecifiekekennis. Het is kennis over het domein ‘voetbal’. Op hethoogste niveau bevindt zich de domeinonafhankelijkekennis. De domeinonafhankelijke kennis is toepasbaar inverschillende domeinen. Het vormt een soort‘grammatica’ voor de domeinspecifieke kennis. Net zo alsdomeinspecifieke kennis er voor zorgt dat mensen desamenhang in feiten en regels sneller en eenvoudigerkunnen inzien, draagt domeinonafhankelijke kennis ertoe bij dat mensen zich veel sneller kennis over eenspecifiek domein kunnen eigen maken.‘Domeinonafhankelijke kennis’ is op het eerste gezicht

Het gezelschap is zich De BlauweKamer gaan noemen. Een beetje

een naam voor geheimzinniggenootschap. Het zou in Harry

Potter niet misstaan.

Een referentiemodel vanhet Nederlands recht

door Reinoud de Leve en Hans Siebering

In 2012 kwamen de Belastingdienst, de IND, de Universiteit vanAmsterdam en PNA bij elkaar om te spreken over de knelpunten in devoortbrenging van de informatievoorziening of de enorme doorlooptijdenvan het opstellen van specificaties die vaak ontstonden bij de realisatievan software systemen op basis van wet en regelgeving. Het was hetbegin van een reeks van samenkomsten. Het gezelschap is zich DeBlauwe Kamer gaan noemen. Een beetje een naam voor geheimzinniggenootschap. Het zou in Harry Potter niet misstaan. Sjir Nijssen is vanafhet eerste uur lid van De Blauwe Kamer. Er is niets geheimzinnigs aanDe Blauwe Kamer, verzekert hij ons. Iedereen mag deelnemen zolanghij meer brengt dan haalt. Het gezelschap heet zo, omdat het eersteoverleg plaats vond in een blauwe kamer. Wij spraken met hem hieroverin het kantoor van het bedrijf PNA in Heerlen, door hem indertijdgesticht.

Amuses DREAM16 9

een beetje abstract begrip. Het is moeilijk om je er ietsconcreets bij voor te stellen. Het lijkt nog complexer teworden als Nijssen snel laat zien dat er geen vierdeniveau bestaat.

In het werk dat Sjir Nijssen de afgelopen vier jaar voorDe Blauwe Kamer heeft gedaan, wordt het een stukduidelijker wat hij bedoelt met domeinonafhankelijkekennis en waarom juist deze domeinonafhankelijkekennis bijdraagt aan betere, wendbaardere, duurzameresoftware systemen voor het verlenen van regelgevinggebaseerde diensten.

Wat is de missie van De Blauwe Kamer?

‘Bij de Belastingdienst heeft men heel goed begrepen dateen politicus heel anders denkt dan een ingenieur. Hetgaat dus fout als je een software engineer direct laatbouwen wat een politicus oplevert. Politici formuleren alsinds een paar honderd jaar de wet en regelgeving ineen juridisch formele taal. Dit heeft enorm veelduidelijkheid gegeven in onze democratische rechtstaat.Deze regels zijn formeel in juridische zin, maar informeel

Sjir Nijssen

Het gaat fout als je een softwareengineer direct laat bouwen wat eenpoliticus oplevert. Dat kun je geen

van beiden kwalijk nemen.

DREAMagazine OKTOBER 201610

in taaltechnische zin. Dit betekent dat als softwareengineers deze regels letterlijk zouden implementeren,dit vaak niet zou leiden tot een kwalitatief goed softwaresysteem. Aangezien we als Blauwe Kamer wet­ enregelgeving als een gegeven beschouwen, is het eenuiterst interessante uitdaging om wet­ en regelgeving omte zetten naar juridisch formele, maar tegelijktaaltechnisch formele duurzame specificaties, voorwendbare wetsuitvoering. De Blauwe Kamer heeft dehoogste prioriteit gegeven aan het opstellen en uittestenvan een werkvoorschrift (protocol) op basis waarvan eenmultidisciplinair team, bestaande uit juristen,dienstenspecialisten en specificeerders de wetten enregels aangevuld met kennis over de dienstverleningomzetten in duurzame en vooral bouwbare specificaties.Daar bovenop eist de Belastingdienst dat alles tweekanten uit traceerbaar is. Van wet naar duurzamespecificatie naar software en terug.’

In welke zin denken politici en juristen nuanders dan ingenieurs?

‘Juristen hebben het vaak over rechtsbetrekkingen. Eenrechtsbetrekking is bijvoorbeeld: “De werknemer kan dewerkgever verzoeken om een aanpassing van zijnarbeidsduur onder voorwaarde dat hij langer dan zesmaanden een dienstbetrekking heeft enzovoort.” Als jeeen jurist zou vragen wat een rechtsbetrekking is, zal hijiets antwoorden als dat het een plicht is die de ene partijheeft ten opzichte van een andere partij die hetbijbehorende soort recht heeft, ten aanzien van eenspecifiek onderwerp. Dat is waar, maar het is maar eendeel van de waarheid. Het heeft mij bijna vier jaar gekosteer ik goed door had hoe het werkelijk zit. Mijn ogenwerden geopend door een boekje uit 1913 van eenzekere mijnheer Hohfeld. Hohfeld was een Amerikaan enhad naar het Amerikaanse recht gekeken. Hij stelde dat

er niet één soort rechtsbetrekking bestond, maar dat ervier verschillende soorten rechtsbetrekkingen zijn. Dit iseen heel belangrijk inzicht, omdat je recht niet goed kuntbegrijpen als je niet inziet dat er verschillende soortenvan rechtsbetrekkingen zijn. Nu is Nederland natuurlijkeen beschaafder land dan Amerika. Ik ben nu, en denkdat ik ze allemaal heb, bij zeven verschillende soortenvan rechtsbetrekkingen uitgekomen voor hetNederlandse recht. Verschillende soorten vanrechtsbetrekkingen hebben een verschillende dynamiekof interactie. Je hebt bijvoorbeeld een fatale verplichtingrechtsbetrekking. Dat is een rechtsbetrekking die, als jehem overtreedt, direct rechtsgevolgen heeft. Je bentmeteen de klos. In het burgerlijk wetboek staan eenheleboel rechtsbetrekkingen waarbij dat helemaal niethet geval is. Als ik zo’n wet overtreed, kan de anderepartij mij in gebreke stellen, maar dat hoeft hij niet tedoen. Begrijp je dat dat een ander soort plicht is?

Juristen denken niet zo over wetten. Laatst belde ik eenjurist. Ik had een vraag over een wetsartikel. Zegt diejurist dat het over arbeidsrecht ging. Hij was fiscaal jurist.Arbeidsrecht was heel iets anders. Zo kijken juristen ertegen aan. Zij zouden voor iedere wetgeving een geheelander systeem maken.’

Behoren die 7 verschillende soorten vanrechtsbetrekkingen tot dedomeinonafhankelijke, of beterwetsonafhankelijke, maar jurisdictie­ entijdsafhankelijke kennis?

‘Precies. Dat is wat de specificeerder zou moetenbijdragen aan het multidiciplinaire team. Eenrechtsbetrekking is een soort toestand tussen debetrokken rechtssubjecten. Wij modelleren een toestandmeestal als een state in een state­transition­diagram. Er

Interview

Amuses DREAM16 11

zijn handelingen of gebeurtenissen die er voor zorgendat je van de ene state in de andere state terecht komt.Dat noemen we in het recht feitelijke handelingen meteen rechtsgevolg of rechtshandelingen ofgebeurtenissen met rechtsgevolg of tijdsverloop metrechtsgevolg. Deze rechtsgevolgveroorzakers zijn op tedelen in 15 patronen. Dit betekent dat we op eengeneriek niveau het hele Nederlandse recht kunnenmodelleren als een state­transition­diagram met 7 statesen 15 transitions. Dit is kennis die voor zover ik hebkunnen nagaan, nog op geen enkele Nederlandsejuridische faculteit wordt onderwezen. Maar als jeduurzame specificaties voor systemen wilt opstellenmoet je de wetgeving wel zo doorgronden.’

Hebben alle landen nu 7 soortenrechtsbetrekkingen en 15 soortenrechtsgevolgveroorzakers?

‘Nee, dat zal per rechtssysteem, vaak aangeduid alsjurisdictie wel iets verschillen. Dat is iets waar we nu nogveel te weinig aandacht voor hebben. We willen dewetten van de Europese landen harmoniseren. Je zult jeechter eerst moeten afvragen of die verschillende landenwel dezelfde soorten rechtsbetrekkingen en soortenrechtsgevolgveroorzakers hebben. Anders kom je er nietgoed uit.’

De tendens tegenwoordig is dat men debusiness steeds vaker direct met deontwikkelaars willen laten spreken. Wat vindtu daar van?

‘In veel gevallen is dat geen goede ontwikkeling. Hetleidt tot meer onduidelijkheid en zorgt ervoor datprojecten langer duren. Ik zou er voor pleiten omspecificeren weer tot een echt vak te maken.’

Referentieshttp://www.DeBlauweKamer.nuhttp://www.WendbareWetsuitvoering.nl

Sjir Nijssen is vanaf 1959 bezig

geweest met zijn professionele

hobby, analyse. Dat heeft hij zowel

gedaan als hoofd opleidingen van de

voorganger van NOVI en EXIN, als

hoofd van een database research lab

voor een grote computer leverancier,

als hoogleraar en als ondernemer.

Het begon allemaal met zijn

diensttijd bij de Koninklijke

Luchtmacht van 1958­1960, bij het

Korps Luchtwachtdienst:

waarnemen, als feiten doorgeven en

plotten. Sinds 2012 is hij nagenoeg

voltijds bezig de verworven kennis

toe te passen voor analyse van wet­

en regelgeving voor de daarop

gebaseerde diensten.

Sjir Nijssen

PNA is expert op het gebied van kennis. PNA helpt

organisaties bij kennisintensieve uitdagingen en

legt het fundament voor duurzaam en intelligent

gebruik van kennis. PNA wil innovatie de ruimte

geven en verspilling van kennis, tijd en geld

tegengaan. Hiervoor ontwikkelde zij de cogNIAM®

methode die geschikt is voor het optimaliseren van

elke vorm van kennis. PNA werkt onder meer voor

ABN AMRO, ADP, Belastingdienst, European

Space Agency, Erasmus Universiteit Rotterdam,

MoneYou, Obvion en VGZ. Haar gedachtegoed

fungeert tegenwoordig als basis voor de actuele

wereldstandaarden op het gebied van processen,

business rules en gegevensmanagement.

DREAMagazine OKTOBER 201612

Een hybride omgeving heeft zowel agile als watervalelementen in zich. Dan zijn de agile technieken niet éénop één toepasbaar, je moet ze aanpassen aan jespecifieke situatie.

Een hybride omgeving kan een bewuste keuze zijn ofmen kan nog midden in de transitie van waterval naaragile zitten. Ik spreek veel analisten die meer agilezouden willen werken, maar daarin belemmerd wordenomdat nog niet iedereen in de organisatie de omslagnaar agile heeft gemaakt. Ze hebben te maken metbelangrijke stakeholders die nog traditioneel denken. Indit artikel vertel ik hoe je dan toch de agilerequirementstechnieken kunt blijven toepassen.

Stakeholders die nog traditioneel denkenAls analist heb je met veel verschillende typenstakeholders te maken. Als bijvoorbeeld hetmanagement nog traditioneel denkt en vasthoudt aan deschijnzekerheid van een traditionele planning, zul je aan

het begin van het traject al behoorlijk ver uitgewerkterequirements moeten aanleveren. Dat geldt ook als eenexterne leverancier ver uitgewerkte requirements nodigheeft om een offerte te maken. Daarnaast hebben veelanalisten te maken met een product owner of metgebruikers(vertegenwoordigers) die geen tijd hebben ofin oplossingen blijven denken. Tot slot vraagt ook eenontwikkelteam, dat gedetailleerd vastgelegderequirements nodig heeft om de software te kunnenbouwen, aanpassing van je agile werkwijze.

Afhankelijk van het aantal en de macht van detraditioneel denkende stakeholders gaat de agile aanpakin meer of mindere mate afwijken van de ‘ideale’ agileaanpak. Je krijgt dan een aanpak die elementen uitzowel agile als waterval in zich heeft. Dat kan allerleiproblemen geven, maar als je weet wat je wel en wat jeniet kunt combineren, werkt het prima. Daarbij komt datagile geen strak voorgeschreven methode is. ‘It is aframework within which you can employ variousprocesses and techniques’, zoals in de officiële ScrumGuide (laatste update juli 2016) te lezen is.

Agile requirements binnende beperkingen van eenhybride omgevingDe afgelopen jaren hebben we massaal de watervalaanpak vaarwelgezegd en agile en Scrum omarmd. Inmiddels is duidelijk geworden datagile zo zijn eigen uitdagingen kent. Dat geldt zeker ook als je in eenhybride omgeving werkt.

Hybride omgeving

door Nicole de Swart

Een hybride omgeving kan eenbewuste keuze zijn of men kan nogmidden in de transitie van waterval

naar agile zitten.

Als je weet wat je wel en wat je nietkunt combineren, werkt het prima.

Amuses DREAM16 13

Doelgericht Requirements achterhalenVoor analisten die willen profiteren van deverworvenheden van agile, is het in de eerste plaats vanbelang om requirements doelgericht te blijvenachterhalen. Dat houdt in dat:

• je primaire focus ligt op het realiseren van debedrijfsdoelstelling.

• je gaandeweg het project ontdekt wat de échtebehoeften van de business zijn.

• je voortschrijdend inzicht bewust stimuleert enrequirements steeds blijft verbeteren.

• de voortgang van het project afgemeten wordt aande te behalen bedrijfsdoelstelling.

Dit in tegenstelling tot de traditionele manier van werken,waarbij:

• je focust op het te ontwikkelen systeem en defunctionele en niet­functionele eisen die daaraangesteld worden (de requirements).

• je requirements voorafgaand aan de bouw opstelt en

ter goedkeuring voorlegt.• je meteen de definitieve requirements probeert te

achterhalen, om het aantal wijzigingen beperkt tehouden.

• de voortgangsbewaking op basis van deafgesproken requirements plaatsvindt.

Beperkingen in een hybride omgevingIn een hybride omgeving is het alles behalvevanzelfsprekend dat je requirements (bedrijfs)doelgerichtachterhaalt. De traditioneel denkende stakeholderszorgen, vaak onbewust, voor allerlei beperkingen. Wat ikmeestal zie gebeuren is dat analisten het doelgerichtwerken (gedeeltelijk) laten vallen ten gunste van detraditionele requirements aanpak. Dat is jammer wantdan blijf je worstelen met de bekende problemen uit deschommelkarikatuur, waar agile en doelgericht werkennu juist een antwoord op hebben gevonden.

Het beste advies dat ik aan analisten in hybrideomgevingen kan geven is

Blijf requirements doelgericht achterhalenen voeg daaraan de in jouw situatienoodzakelijke traditionele aspecten toe.

Toevoegingen die in jouw situatie misschien noodzakelijkzijn, zijn bijvoorbeeld dat je:

• gaat werken met een voorbereidingsteam metanalisten die een aantal sprints vooruit werken. Zo’nteam is in veel organisaties een goede toevoeging,maar blijf je realiseren dat het symptoombestrijdingis.

Nicole de Swart

Voor analisten die willen profiterenvan de verworvenheden van agile, is

het in de eerste plaats van belangom requirements

(bedrijfs)doelgericht te blijvenachterhalen.

DREAMagazine OKTOBER 201614

• requirements toch vroegtijdig gaat opstellen (langvoor de sprint waarin het ontwikkelteam ze oppakt).Als je daar later maar van af kunt wijken en ervoorzorgt dat dit het voortschrijdend inzicht nietbelemmert, is het best in te passen in je doelgerichtewerkwijze.

• bij het sprint ready maken van product backlog­items meer details gaat vastleggen dan in agilenodig zou zijn. Dat is goed mogelijk zonder afbreukte doen aan de doelgerichte werkwijze.

• requirements toch uitgebreid en gedetailleerd gaatdocumenteren ten behoeve van beheer enonderhoud. Dat is prima te combineren met eendoelgerichte werkwijze.

• traditionele voortgangsrapportages voor deopdrachtgever maakt (of dat aan je projectleideroverlaat).

InefficiëntiesAan deze voorbeelden zie je dat de traditioneletoevoegingen substantieel extra werk opleveren en dusbehoorlijk wat tijd en geld kosten. Je introduceertinefficiënties. Zolang die toevoegingen niet ten kostegaan van de effectiviteit, kan het een verstandige keuzezijn. Het mooie bij agile en Scrum is dat de extra kosteneenvoudig inzichtelijk te maken zijn. Dit stelt deorganisatie in staat om een gefundeerde keuze te

maken: ‘nemen we de kosten voor lief of gaan wegroeien naar een meer agile organisatie?’.

Verlies van effectiviteitHet wordt vervelender als een traditionele toevoegingnaast tijd en geld ook de effectiviteit negatief beïnvloedt.Dat is het geval als er aan de essentie van dedoelgerichte werkwijze wordt getornd en dus debedrijfsdoelstellingen niet of minder goed gerealiseerdworden. Oorzaak kan zijn dat het voortschrijdend inzichtbelemmerd wordt of dat gewijzigde inzichten nietmeegenomen worden bij de realisatie van de software,denk bijvoorbeeld aan:

• Stakeholders die blijven vasthouden aan eerdergoedgekeurde requirements.

• Een softwarearchitectuur die gebaseerd is opvroegtijdig opgestelde requirements en hetdoorvoeren van (pas later ontdekte) wijzigenbelemmert.

• Een strak wijzigingsbeheerproces waarin belangrijkewijzigingsverzoeken geweigerd worden.

SamenvattingIn een hybride omgeving ben je genoodzaakt om agile entraditionele requirements te combineren.Als je niet weet wat je wel en wat je niet kuntcombineren, geeft dat al snel problemen. Meestal komtdat doordat, onder druk van de nog traditioneeldenkende stakeholders, de doelgerichte werkwijze wordtlosgelaten.

Mijn advies aan analisten in hybride omgevingen is danook achterhaal requirements doelgericht en voegdaaraan de in jouw situatie noodzakelijke traditioneleaspecten toe. Dat je gecombineerde agile en traditionelewerkwijze minder efficiënt is valt niet te vermijden, maarde effectiviteit blijft dan in ieder geval gewaarborgd.

Het wordt vervelender als eentraditionele toevoeging naast tijd en

geld ook de effectiviteit negatiefbeïnvloedt. Dat is het geval als er

aan de essentie van de doelgerichtewerkwijze wordt getornd.

Hybride omgeving

Nicole de Swart helpt

analisten in complexe en

hybride omgevingen de

juiste agile en traditionele

technieken toepassen.

Dat doet ze via de Reaco

Academy door informatie

en tips te delen (bijna

4.500 abonnees) en door

cursussen en training­on­

the­job programma’s te

geven. Nicole is auteur

van Handboek

Requirements en van Grip

op Requirements.

Amuses DREAM16 15

Priya Soekhai

Hoe ben je met dit boek in aanraking gekomen,wat deed het je en waarom wil je juist hierovergraag met ons praten?

Mijn vriend, die Java ontwikkelaar is, kwam ermee. Opdat moment heb ik het weggelegd. Later vertelde eencollega bij de bank me erover. Toen heb ik het gelezen.Ik had het in één avond uit en spijt (!) dat ik het al die tijdhad laten liggen. Ik raakte steeds meer geïntrigeerd doorhet onderwerp zelf, maar vooral door de technieken, dieerin zitten. Enerzijds door het principe: het onmogelijkemogelijk maken; van de nood een deugd maken; hetprobleem wordt de bedoeling. Dat is een heel anderevisie op wat vaak een uitdaging wordt genoemd, maar inwerkelijkheid een probleem is. Anderzijds trok het meaan, omdat ik werkzaam ben op het gebied vanrequirements. Omdenken gaat over problemen totmogelijkheden maken en requirements gáán overmogelijkheden, de link ligt voor de hand. Ik heb zelfgemerkt dat je in het proces van het mogelijk maken of

realiseren van requirements, tegen problemen aanloopt.Problemen, die ontstaan omdat er veranderingen in gangworden gezet. Je haalt processen uit een patroon, waariedereen aan gewend was. Een verandering wordt nietaltijd gezien als een verbetering. Vaak niet zelfs. Wat isomdenken nu precies? Het boek begint met het uitleggenvan het begrip vastdenken: beren op de weg zien,waardoor het een complete ramp lijkt te worden.Omdenken is dat je daarin meebeweegt op een heelflexibele manier.

De mooiste illustratie daarvan vind ik, dat waar het glasvoor de één half leeg is en voor de ander half vol, deomdenker vraagt: waar is de kraan, want dan kan ik hetvullen en dan zijn beiden tevreden. Dat mechanisme kunje in het proces van requirements engineering heel goedgebruiken. Ik probeer de technieken toe te passen, die inhet omdenken zijn ontwikkeld en worden aangeboden. Inhet proces van het invoeren van veranderingen, maarook in het managen van verwachtingen, want ook daar

In deze serie interviews spreken Hans Siebering enReinoud de Leve telkens met een collega requirementsengineer naar aanleiding van een artikel of een boek dathem of haar inspireerde. Deze keer spreken ze met Priya Soekhai overhet boek ‘Omdenken – kijk – denk – creëer’ van Berthold Gunster.door Hans Siebering en Reinoud de Leve

Het concept ‘omdenken’ is bedacht door Berthold Gunster. Hij is van huisuit theaterregisseur en timmert al zo’n 20 jaar aan de weg met trainingenen workshops aan bedrijven en particulieren over ‘ja­maar’ en‘omdenken’. Hij trekt met een theatershow met wekelijkse voorstellingendoor heel Nederland. En hij schreef over zijn gedachtegoed een aantalgoed verkochte boeken. Het eerste daarvan, ‘Ja­maar wat als alles lukt’,werd in 2006 genomineerd als managementboek van het jaar.

Omdenken of ja­en­denken is een methode om problemen tetransformeren in mogelijkheden. Omdenken staat tegenover vastdenkenof ja­maar­denken. Er zijn 15 manieren om om te denken, die toegepastkunnen worden in liefde, werk, strijd en spel. Altijd pas je de volgendetwee stappen toe:• Deconstrueren is van het probleem een feit maken. Je neemt een

probleem, haalt daar af wat­er­zou­moeten­zijn en houdt dat­wat­er­isover.• Construeren is het transformeren van bestaande feiten tot een

nieuwe mogelijkheid. Je start met een feit, en kijkt wat je daar mee zoukunnen doen.

Zie voor meer informatie http://www.omdenken.nl.

DREAMagazine OKTOBER 201616

gaat omdenken vaak over. Vaak gaat het niet zozeerover de verandering zelf, maar over de verwachting, diedaaraan gekoppeld is. En over wat die mogelijk teweegkan brengen. Omdenken geeft antwoord op de vraaghoe je daarmee omgaat.

De schrijver zet een spanningsveld op tussenenerzijds vastdenken, waarbij je doorgaat meteen bestaande techniek – waardoor je van eenprobleem een ramp maakt – en anderzijdsomdenken, waarbij je de situatie accepteert.Heb je concrete voorbeelden, waarbij je in jewerk tegen vastdenken aangelopen bent?

Ik hoor veel standaard opmerkingen, zoals: ‘Dit gaat nietwerken’. Mensen zien vaak eerder de bedreigingen vaneen verandering, dan de kansen. Iemand heeftbijvoorbeeld al vaak aangegeven, dat een belangrijkbedrijfsproces efficiënter kan. Dan komt het moment, dater een kans is om dat proces te automatiseren, en dankomt de opmerking: ‘ja maar … hebben we aan ditscenario gedacht, hebben we aan dat scenario gedacht?… wat als de klant op verschillende manieren gaatreageren? … hoe verwijzen we van het ene proces naarhet andere proces?’. Het is op zich hartstikke goed datdeze vragen naar voren worden gebracht, maar erworden dan zoveel scenario’s mét problemenopgeworpen, dat het daadwerkelijk online zetten van hetproces moeizaam verloopt. Wat we ooit bedacht hadden:

‘als we het proces volledig automatiseren, leveren weklantwaarde, businesswaarde en komt er ruimte voor aldie andere dingen die we ook nog hadden willen doen’,dat sneeuwt dan volledig onder.

Speelt hier ook mee dat mensen zich bedreigdvoelen in hun positie?

Ja, zeer zeker. Want de rol die je had krijgt mogelijk eenheel andere invulling. Mensen vergeten daardoor vaakdat juist die andere invulling nieuwe perspectieven biedten mogelijk datgene oplevert wat ze graag hadden willenzien of doen. De eerste reactie is helaas vaak weerstand.Ik ben vaak werkzaam in projecten waar online dienstenworden aangeboden. De ambitie is hoog. Klanten willensteeds meer zelf (kunnen doen), in sommige gevallenvolledig zelfstandig processen initiëren, volgen en ookafronden, zonder tussenkomst van mensen. Om dit soortprocessen juist en volledig te automatiseren heb jeeenduidigheid nodig. Om die eenduidigheid te vindenlopen we in de rol van requirements engineer samen metstakeholders de processtappen en de scenario’s langszodat we de oplossing kunnen bepalen. Als stakeholdersvervolgens allerlei redenen opwerpen om aan te gevendat bijna elke oplossing (behalve de optimale) niet goedgenoeg is, dan kost dat enorm veel tijd. Ik ervaar dittelkens als een ‘ja maar, dit gaat niet werken’­moment.We komen er uiteindelijk stapje voor stapje achter wathier eigenlijk speelt. Door goed door te vragen om dekern van het probleem vast te kunnen stellen, zodat dejuiste oplossing kan worden bepaald.

Kom je in je werk ook situaties tegen, waarin jeziet dat omdenken wordt toegepast?

We moesten bepalen of klanten in aanmerking kwamenvoor een bepaalde korting. In sommige gevallen kon deklant zelfs twee keer korting krijgen. We moesten toenmet de business bepalen welke categorieën van klantende korting(en) zouden krijgen. Daar kwamen we, sessiena sessie, niet uit. Totdat één van de analistenvoorstelde: laten we alle klanten de extra korting geven.Als achteraf blijkt dat een klant niet aan de voorwaardenvoldoet, dan gaan we handelen. Het was veeleenvoudiger om te bepalen dat een klant niet aan devoorwaarden voldoet. Daarmee maakten we van hetprobleem de bedoeling.

We hebben de techniek, waarbij je van het probleem debedoeling maakt, ook andersom toegepast. Het lukte debusiness niet om een pakket met requirements voor eennieuwe wens in te kaderen. Telkens kwam er iets bij dateigenlijk ook meegenomen moest worden. Eigenlijk wildemen een totaaloplossing. Toen zei de projectleider: okee,dan doen we het hele pakket. De impact werduitgevraagd. Het bleek dat we over een jaar live kondengaan. Dat gaf een schok: dat was niet de bedoeling.Daarna bleek het plotseling toch mogelijk om derequirements op te knippen. Doordat men zichrealiseerde wat de oplossing was ontstond er een anderebeweging.

Interview

Amuses DREAM16 17

Wat zijn de dingen waar je op moet letten omgoed om te kunnen denken?

Om goed te kunnen omdenken moet je de scheidingkunnen maken tussen de feiten en de beleving van defeiten. Daardoor wordt het mogelijk om op een anderemanier naar de feiten te kijken. Het scheiden van feitenen beleving doe je door dóór te vragen. Met concretegegevens werken. Cijfers: meten is weten. Aantallen:veel? wat is veel? 10? 1000? Verder is alertheid in hetmoment belangrijk. In een project kwamen we er dooralertheid achter dat er in het proces nog een belangrijkeextra rol zat. Die werd nauwelijks genoemd, maar bleekimpact te hebben op het autorisatiemodel. Door teonderzoeken om welke aantallen het ging konden deimpact en de oplossing concreet gemaakt worden.

Gunster noemt een aantal technieken. Welkedaarvan spreken je aan?

De techniek, die wu wei heet: wat gebeurt er als we ditniet doen? Het is een techniek die uit het taoïsme komt.Als je die vraag stelt gaan mensen achterover zitten, metde opmerking: hoezo, gaan we dit niet doen? Deze

techniek heb ik toegepast toen een e­mailgeoptimaliseerd moest worden. De vormgeving moestanders, de lay­out, de tone of voice. Ik heb de wu weivraag gesteld. Het resultaat was dat de requirementsover de verandering van de vormgeving verdwenen.

Op de zijflap van het boekje staan grappendeen aantal negatieve uitspraken van lezersover het boekje. Onder andere dat de inhoudvan het boekje nog dunner is dan het boekjezelf. Het is duidelijk dat jij deze uitspraak nietondersteunt. Wat zou jij op de flap zetten?

‘Less is more’. Omdat ik vind dat er zoveel boeken zijngeschreven die open deuren intrappen, waar we zo naarbinnen kunnen lopen. Ik vind dit een creatieve enbijzondere manier van omgaan met problemen en omoplossingen te bedenken. Het lijkt eenvoudig, maar het isbest moeilijk om de technieken te beschrijven en er dejuiste voorbeelden bij te geven. Hoe dun het boekje ookis, het is een hele uitdaging om dit te beheersen. Ik denkdat hij minder had overgebracht als hij er meer over hadgeschreven. Less is more geldt wat mij betreft ook voorde keuze van de technieken. Hij beschrijft er in zijnmethode vijftien en er is overlap tussen verschillendetechnieken. In dit boekje komen er maar 3 of 5 aan deorde. Ik ben dol op het toepassen van een top 3 of somseen top 5. Als het boek niet meer dan 3 pagina’s hadgehad, had Berthold Gunster wat mij betreft eenstandbeeld mogen krijgen.

Priya Soekhai

Berthold Gunster reageert op dit interview.

“De observatie dat omdenken begint met het onderscheid

maken tussen feiten en fictie is cruciaal. Mensen denken altijd

dat een probleem één ding is. Een ontslag. Een spijbelend kind.

Een regenbui. Maar een probleem is altijd twee dingen; een

probleem is per definitie de spanning tussen wat­er­is (de

werkelijkheid, de feiten) en dat wat er zou­moeten­zijn (onze

verwachtingen, de fictie). Als je wilt zonnebaden op het strand is

een regenbui een probleem, maar voor een boer kan een

regenbui soms zeer gewenst zijn. Of iets een probleem is, hangt

dus niet alleen af van de feiten, maar ook van onze

verwachtingen.

Om goed te kunnen omdenken is het dan ook belangrijk dat je

beide elementen zo accuraat mogelijk kunt benoemen. Wat is er

precies aan de hand (feitelijk, wetenschappelijk, meetbaar,

onderbouwd met feiten) en wat willen wij precies (wat is onze

ambitie, ons verlangen, wat zijn onze doelstellingen).

Mensen denken vaak dat je om te kunnen omdenken creatief moet zijn, maar de eerste stap van het

omdenken vergt juist een zeer analytische, observerende geest. Hoe beter je waarneemt, des te creatiever je

wordt. Het goede van het artikel is dat dat zeer duidelijk naar voren komt.”

Wat gebeurt er als we dit niet doen?

DREAMagazine OKTOBER 201618

Gefrustreerd zoeken we onder iedere steen naaraanwijzingen om incomplete en veranderenderequirements te voorkomen. Aan de Universiteit Utrechtkrijgen we regelmatig vragen als “Hoe komen we achterwensen die niet tijdens het voortraject besproken wordenzoals eenvoudige software configuratie?”.

Helaas bestaat er geen opleiding tot helderziende. Welzijn er héél veel methoden die beloven je te helpenperfecte requirements te formuleren. Compleet,ondubbelzinnig, in tegenwoordige tijd, etcetera. Maar is

dit wel nodig? Opmerkelijk genoeg zijn er aanwijzingendat projecten met requirements die veel veranderenhelemaal niet minder succesvol zijn of meer kosten danprojecten met requirements die niet of weinigveranderen. In een recente studie uit Noorwegen [1]waren projecten die requirements het vaakstveranderden naar aanleiding van nieuwe informatiesuccesvoller dan projecten met weinig of geenveranderde requirements. Deze projecten leverden inminder tijd hogere kwaliteit software tegen lagere kosten.

Voortschrijdend inzichtNiets zo veranderlijk als requirements. Dat is vervelend. En duur.Althans, dat zeggen we graag tegen elkaar. In theorie voorkomt iederuur dat je steekt in requirements engineering minimaal tien uur onnodigwerk. Maar hoe erg we ons best ook doen om scherpe requirements teformuleren, er is altijd íéts wat anders moet. Soms met desastreuzegevolgen.

Requirements "engineering"?

door Garm Lucassen, Universiteit Utrecht

Het Quality User Story Framework van de Grimm Methode definieert 13 karakteristieken van een goede user story.

Amuses DREAM16 19

Maar hoe zit het dan met al die rapporten die bewerendat requirements wél de oorzaak zijn? Ieder jaar vullenduizenden IT managers een enquête in van de StandishGroup. Zij stellen vervolgens het wereldberoemde“Chaos Report” op ter verklaring van gefaalde en te duuruitgevallen IT projecten. Jaar na jaar zijn incomplete enveranderende requirements de boosdoeners. Datiedereen de schuld geeft aan requirements, betekent nietdat ze daadwerkelijk de schuldige zijn. Hooguit dat ze demeest voor de hand liggende zondebok zijn. Voor veel ITmanagers komt het wel goed uit requirements de schuldte geven…

Het heeft er alle schijn van dat het beter is om de chaoste omarmen dan te proberen de controle te krijgen doororde te scheppen. Wat mij betreft beperkt dit inzicht zichniet tot veranderende requirements. Bij het creëren enopstellen van requirements is streven naar perfectie eennutteloze exercitie. Dat valt uit gangbare requirementskwaliteitsraamwerken echter niet op te maken. De ISO29148 Requirements Engineering standaard introduceertbijvoorbeeld 13 karakteristieken voor een well­formedrequirement en stelt dat “checking for thesecharacteristics is critical to avoiding requirementschanges”. Naast de discutabele aard van het beoogdedoel van deze karakteristieken, zijn er bar weinigaanwijzingen dat deze criteria daadwerkelijk eenpositieve invloed hebben. Veel verder dan dat incorrecterequirements leiden tot incorrecte software komen weeigenlijk niet. Tegelijkertijd bestaan er wel studies metresultaten die tegen “algemeen geaccepteerde”richtlijnen indruisen: requirements formuleren in passieveof ontkennende zin heeft geen negatieve invloed op hetsoftware­ontwikkelingsproces [2, 3]. Blijkbaar zijnsoftware developers prima in staat zelfstandig tehandelen in belang van het product. Als de requirementscorrect zijn, maakt het eigenlijk niet zoveel uit hoe ze zijnopgeschreven. En hoe zit het dan met al die anderekwaliteitscriteria als unambiguous, feasible of conflict­free? Helaas geldt voor dit soort criteria dat het vrijwelonmogelijk is om hun impact ondubbelzinnig vast testellen. De huidige onderzoeksbudgetten en beperktewetenschappelijke interesse van software­bedrijven en

­medewerkers maken het vrijwel onmogelijk debenodigde grootschalige studies uit te voeren.

Heeft het überhaupt zin om requirements te engineeren?Het is van belang om de faciliterende rol vanrequirements engineering in het achterhoofd te houden.Het is in de eerste plaats belangrijk de te ontwikkelensoftware af te stemmen richting klant en/of eindgebruiker.In de tweede plaats wil je de requirements effectief interncommuniceren. De intrinsieke kwaliteit van derequirements is hierbij eigenlijk van ondergeschiktbelang. Als het werkt, dan is het voldoende. Deze maniervan kijken naar requirements sluit goed aan bij het agilegedachtegoed. Op eenzelfde wijze proberen we bij deUniversiteit Utrecht ons kwaliteitsraamwerk voor userstories aan te prijzen. Het Quality User Story Frameworkvan de Grimm Methode is gebaseerd op een kritischeanalyse van honderden user stories, waarna we 13karakteristieken hebben geformuleerd waarvan wijgezien hebben dat het misgaat in de praktijk(http://garmlucassen.nl/grimm). Ze zijn echter nietallemaal ontegenzeggelijk relevant voor iedere userstory. We raden daarom aan jouw user stories pas aaneen karakteristiek te toetsen als je voor jezelf het nutervan kan rechtvaardigen ongeacht de beperkte invloedop software succes. Een voorbeeld: het komt hetprofessionele imago van een projectbureau ten goedewanneer zij op een consistente, uniforme wijze userstories communiceren richting de klant. Bovendiendoorlopen stakeholders een verzameling user storiessneller wanneer je ze formuleert volgens één template.Voor een startend game development bedrijf met vijftiguser stories is dit criterium “uniformity” verwaarloosbaar.Externe stakeholders krijgen de user stories toch nooit tezien.

Voortschrijdend inzicht

De huidige onderzoeksbudgetten enbeperkte wetenschappelijke

interesse van software­bedrijven en­medewerkers maken het vrijwel

onmogelijk de benodigdegrootschalige studies uit te voeren.

Voorbeeld van het type foutmeldingen dat de Grimm User Story Tool inJira plaatst bij de user story: “As a Tentant, i want to resolve complaintswithout intervention from the superintendent and indicate why(optional)”

Nog een voorbeeld van foutmeldingen. Nu bij user story: “Move loginbutton to top right”

DREAMagazine OKTOBER 201620

Requirements "engineering"?

Na het kiezen van een kwaliteitsraamwerk is het handigintern een achterliggende bedrijfsfilosofie tecommuniceren voor het selecteren van de relevantekwaliteitscriteria. Hierdoor ontstaan er zelfsturendeteams die op basis van dit uitgangspunt kunnenbeslissen over hun eigen kwaliteitsstandaard. Zelf ben ikfan van 37signals’ filosofie: optimize for happiness.Levert het expliciet vastleggen van dependencies tussenrequirements weinig voordelen maar veel onvrede op inéén van de teams? Dan kan dat team zelfstandigbeslissen dit kwaliteitscriterium niet langer toe te passen.Een simpele methode ter verzekering dat requirementsde stakeholders blijven dienen.

ToolsHoewel het belang van kwaliteitscriteria voorrequirements onzeker is, blijft het onderwerponverminderd populair. De aanhoudende groei vanDREAM is een duidelijk signaal. Ook voorwetenschappers blijft het verbeteren van requirementsengineering practices een belangrijk streven. Ieder jaarzijn er verschillende congressen en workshops om devoortgang te bespreken: RE, REFSQ, AIRE, MoDRE enga zo maar door. In de afgelopen 15 jaar hebben zijminimaal 20 tools ontwikkeld die fouten in requirementsdetecteren. De kans dat je ooit gehoord hebt van de

namen QuARS, UIMA of SREE is echter minuscuul, laatstaan dat je ze ooit hebt gebruikt. Dat is ook niet zo gek,aangezien slechts een derde van die 20 nog beschikbaaris. De rest is van het internet verdwenen en deontwikkelaars zijn onbereikbaar. Ontzettend zonde enhelaas is deze kennisvernietiging onvermijdbaarvanwege de volgende dynamiek:1 Vrijwel alle tools hebben als doel gebruikers te

ondersteunen perfecte requirements te creëren. Aanhet begin van het project doen de ontwikkelaarsgrote beloften op basis van grootse visies van detoekomst. Als het project eenmaal gestart is, blijkt deongestructureerde taal van requirements nog steedsmoeilijk te doorgronden met de huidige kunstmatigeintelligentie. In theorie is het zonder technologischesingulariteit zelfs onmogelijk [4]! Ondanks dezetegenslag vordert het project gestaag en levert het

Hoewel het belang vankwaliteitscriteria voor requirements

onzeker is, blijft het onderwerponverminderd populair.

Automatische groepering van user story concepten op basis van hun betekenis.

Amuses DREAM16 21

Voortschrijdend inzichtteam na een jaar versie 1 op. De onderliggendetechnologie is echter verre van perfect en produceertslechts in de helft van de tijd nuttige rapporten.Gebruikers verliezen snel interesse.

2 De ontwikkelaars laten zich niet zo makkelijk uit hetveld slaan en gaan op zoek naar manieren om detool output te verbeteren. Versie 2 introduceert eeninterface om de output te corrigeren, accepteertalleen requirements in een controlled naturallanguage die de tool beter kan ontleden of vereistvan de gebruiker dat zij iedere requirementhandmatig van extra informatie voorziet zodat detool beter begrijpt wat er staat. Één probleem:gebruikers hebben helemaal geen zin om deze extrastappen te doorlopen, laat staan dat ze er tijd voorhebben! De paar overgebleven gebruikers vanversie 1 omarmen de innovaties van versie 2 niet.

3 Na vier jaar loopt het project teneinde en deuiteindelijke resultaten vallen tegen. Omdat hethuidige academische systeem vooral nieuweresultaten beloont, besluiten de ontwikkelaars zichop andere projecten te storten. De tool is nog steedste downloaden via de projectwebsite, maar deverouderde tool ondersteunen voor mensen die detool even willen proberen zonder financieel teondersteunen kost veel tijd en energie. Niet veellater is de tool verdwenen.

Aan de Universiteit Utrecht proberen we dit scenario tevoorkomen. Zo erkennen we dat het onmogelijk isbepaalde requirements defecten te detecteren op eenbetrouwbare wijze. Daarom probeert onze tool het nieteens. In plaats daarvan richt de Grimm User Story Tool(http://aqusa.nl) zich op simpelere problemen die we metbijna 100% nauwkeurigheid kunnen opsporen. Denkhierbij aan het vinden van user stories met eenongebruikelijke structuur of markeren van misplaatstedetails in de story zoals “Note: ask Jennifer in accountingfor details”. Daarnaast probeert de Grimm Tool zo minmogelijk opdringerig te zijn door te integreren met jehuidige werkwijze. In plaats van extra stappen teintroduceren in je requirements workflow, plaatst de toolautomatisch een reactie in populaire issue trackers alsJira wanneer er iets valt aan te merken op je user story.Vervolgens is het aan jou om iets met deze informatie tedoen.

De eerste prestatiemetingen van de tool tonen aan datdoor de Grimm User Story Tool te introduceren in jeteam, het aantal user story defecten afneemt met 40%.

Daarnaast blijkt dat ogenschijnlijk simpelekwaliteitsdefecten vaak een symptoom zijn van eendrastischer onderliggend probleem. De Grimm Tooldetecteert bijvoorbeeld de haakjes in “As a Visitor, I wantto get messages from the system (tricks etc)”. Het ligtvoor de hand om de tekst (tricks etc) te verwijderen omde tool tevreden te stellen. Maar juist het stukje (tricksetc) bevat de belangrijkste informatie. Na overleg besluithet team meerdere afzonderlijke stories te formuleren:één voor iedere type bericht dat bezoekers kunnenontvangen. Dit neveneffect op de user story kwaliteithadden we niet voorzien. Ondanks deze positieveresultaten gaven beta­testers niet aan dat de kwaliteitvan hun user stories daadwerkelijk was toegenomen.Één van de deelnemers verklaarde dit als volgt: “Ik denkdat er wel verbetering is. Het kwaliteitscijfer is misschienhetzelfde gebleven, maar mijn verwachting is andersgeworden”. Dat hadden we ook niet voorzien…

Het is alleen nog wel de vraag of we de val van hetacademische systeem kunnen voorkomen. De ontvangstvan de tool is tot dusver positief, maar degebruikersaantallen moeten flink groeien om op langetermijn levensvatbaar te blijven. Met dit in hetachterhoofd werken we nu aan een opgefriste interfacevoor de Grimm Tool en ontwikkelen we aanvullendetechnologie om meer waarde te creëren voor gebruikers.Hierbij zetten we sterk in op het visualiseren van userstories op een voor non­technische stakeholdersbehapbare manier. Zo generen we bijvoorbeeldfunctionele modellen op basis van de user stories in eensprint of epic. De output is niet 100% accuraat, maarproduceert wel een representatieve illustratie van hetsysteem. In de eerste evaluaties geven project managersaan dat ze de visualisaties kunnen gebruiken om opsimpele wijze de opbouw van een applicatie uit te leggen

We erkennen dat het onmogelijk isbepaalde requirements defecten te

detecteren op een betrouwbarewijze. Daarom probeert onze tool

het niet eens.

Gegenereerd model van concepten en relaties tussen de concepten opbasis van een automatische analyse van een verzameling user stories.

DREAMagazine OKTOBER 201622

aan non­technische stakeholders. Neem contact op metg.lucassen@uu.nl om de tools uit te proberen, of als jeals organisatie überhaupt interesse hebt om bij te dragenaan wetenschappelijk onderzoek. We waarderen inputvanuit de praktijk namelijk ontzettend!

Referenties[1] M. Jørgensen, A survey on the characteristics ofprojects with success in delivering client benefits,Information and Software Technology, Volume 78,October 2016, Pages 83­94, ISSN 0950­5849.[2] J. Krisch and F. Houdek, "The myth of bad passivevoice and weak words an empirical investigation in theautomotive industry," 2015 IEEE 23rd InternationalRequirements Engineering Conference (RE), Ottawa,

ON, 2015, pp. 344­351.[3] J. Mund, D. Mendez Fernandez, H. Femmer and J.Eckhardt, "Does Quality of Requirements SpecificationsMatter? Combined Results of Two Empirical Studies,"2015 ACM/IEEE International Symposium on EmpiricalSoftware Engineering and Measurement (ESEM),Beijing, 2015, pp. 1­10.[4] K. Ryan, "The role of natural language inrequirements engineering," Requirements Engineering,1993., Proceedings of IEEE International Symposium on,San Diego, CA, 1993, pp. 240­242.[5] G. Lucassen, F. Dalpiaz, J.M.E.M. van der Werf, S.Brinkkemper. Improving agile requirements: the QualityUser Story framework and tool. RequirementsEngineering, 2016, pp 383­403.

Garm Lucassen is promovendus aan de Universiteit Utrecht. Zijn onderzoeksresultaten verklaren

waarom user stories überhaupt effectief zijn en beschrijven richtlijnen voor het creëren van betere

user stories. Op het moment ontwikkelt hij samen met het bedrijfsleven visualisatie­tools die het

makkelijker maken een diepgaand gesprek te voeren over een verzameling user stories. Mail naar

g.lucassen@uu.nl voor toegang tot bètaversies en meer informatie over hoe jouw organisatie op een

laagdrempelige manier kan bijdragen.

Daarnaast organiseert Garm in samenwerking met prof. dr. Sjaak Brinkkemper tweemaal per jaar de

cursus software product management. Gedurende tien sessies leren cursisten hoe software product

management effectief in te vullen in een snel veranderende, Agile werkomgeving. Lees meer over de

cursus en het behalen van het ISPMA Foundation Level Certificate op

http://www.softwareproductmanagement.org/

Requirements "engineering"

Amuses DREAM16 23

Wat is de gedachte geweest om dit model in een artikelte publiceren?

Theo Meeuwissen is medeauteur van het Basisbedrijfs­model Terreinbeheer. Hij was destijds hoofd van deafdeling Beheer en Planning van Staatsbosbeheer ennauw betrokken bij de implementatie van een bedrijfs­

breed softwarepakket. Staatsbosbeheer kan wordengekenmerkt als een terreinbeherende organisatie (TBO)en het softwarepakket als een Enterprise ResourcePlanning pakket op het gebied van terreinbeheer.Tijdens de implementatie van het pakket ontstond eensterke behoefte naar een beter inzicht in de samenhangvan de businessfuncties in het primaire proces van de

Systeembenadering vanterreinbeheerFrank Steeneken is een procesarchitect en heeft samen met TheoMeeuwissen een artikel geschreven over het Basisbedrijfsmodel voorTerreinbeheer in XR­magazine. Het Basisbedrijfsmodel Terreinbeheer iseen herbruikbaar model dat laat zien wat een terreinbeherendeorganisatie (TBO) doet om zijn primaire functie te vervullen. TBO’szorgen voor dagelijks beheer en ontwikkeling van terreinen: bossen,natuurgebieden, historisch cultuurlandschap en (rijks)monumenten in delandschappelijke context van de beheerde gebieden. Het model laat isontwikkeld m.b.v. de Integrated Modeling Method, wat laat zien dat elkbedrijf dezelfde inherente systeemstructuur bezit.

Systeembenadering van terreinbeheer

door Johan Oldenziel en Linda Haak ­ van der Spek

Basisbedrijfsmodel voorterreinbeheerHet model bevat subsystemen (groen)waar kernprocessen (blauw) overheengelegd kunnen worden. De details van desubsystemen gaan bijvoorbeeld overmarktrelatie, product transport,vermogensbeheer. Als je een subsysteemmet een kernproces combineert dan krijg jeeen businessfunctie (geel). Alles bij elkaarwordt dan een grote matrix metbusinessfuncties. Dit totale raamwerk kunje gebruiken om bedrijfsprocessen,procesontwerpen en verbeteringen in kaartte brengen binnen de wereld vanTerreinbeheer.

DREAMagazine OKTOBER 201624

terreinbeheerder. Hierdoor kwam ik als procesarchitect incontact met Theo. Theo en ik hebben daarna het modeluitgewerkt met behulp van de Integrated ModelingMethod (IMM).Wij hadden gemerkt dat andere TBO’s in Nederland endaarbuiten bij de implementatie van softwarepakketten

met dezelfde problematiek werden geconfronteerd. Hetmodel en de toelichting daarvan in de vorm van eenartikel zouden hen daarbij kunnen helpen.Anderzijds was het een mooie gelegenheid om detoepasbaarheid van IMM aan te tonen. Ik heb in hetverleden zeer intensief contact gehad met Dave Ackleybij de ontwikkeling van een soortgelijk model voor hetsupermarktbedrijf. Kort nadat het model gereed was engepubliceerd op de website van Business ProcessTrends overleed Dave op de leeftijd van 82 jaar. Hetartikel is daarom ook als een postuum eerbetoon aanhem bedoeld.

Waarom is dit model naar jouw mening zo belangrijk dat dit breedbekend moet worden?

Het is een universeel functioneel model van toepassingvoor iedere TBO. Het model kan worden gebruikt bij hetsnel doorgronden van de wijze waarop een TBO zijndoelen kan bereiken. Ik ben erg enthousiast over detoepasbaarheid van IMM.

Het concept van Integrated Modeling Method (IMM), datlaat zien dat elk bedrijf dezelfde inherentesysteemstructuur bezit, vinden wij interessant. Alsrequirements engineer ben je vaak op zoek naarherbruikbare concepten. Betekent dit ook dat het modelTerreinbeheer/Supermarkt herbruikbaar is voor anderebranches, bijvoorbeeld overheid en banken. Of is hetvooral te gebruiken binnen de verschillendeterreinbeherende organisaties dan wel supermarkten?

Ackley zegt op zijn website every business enterprisehas the same inherent system structure. Zijn aanpak isgericht op bedrijven die hulpbronnen en of grondstoffenomzetten in respectievelijke diensten en/of producten. Ditleidt ertoe dat je in elke zakelijke onderneming tweesubsystemen kan onderkennen. Het ene subsysteembetrekt hulpbronnen en/of grondstoffen van zijnleveranciersmarkt en stelt die ter beschikking aan hetandere subsysteem, dat diensten en/of producten aanzijn klantenmarkt levert.Daarnaast volgt het business concept van elkeonderneming een life cycle. Het business concept is de(marketing)formule waarmee het bedrijf verwacht zijnprimaire doelstelling te realiseren. Het is eengebalanceerde mix van diensten en producten, diebijdragen aan de opbrengsten, afhankelijk van o.a.sociaal maatschappelijke en economische factoren.Hierbij staan de behoeften van klanten in het middelpunt.De fasen in de life cycle van het business concept komenovereen met de kernprocessen van een bedrijf. Door desubsysteemstructuur te combineren met de structuur vankernprocessen ontstaat een raamwerk vanbusinessfuncties dat op hoofdlijnen gemeenschappelijk isvoor ieder type bedrijf. Ga je vervolgens de subsystemenverder verfijnen dan ontstaan er wel kleine verschillen inhet raamwerk per type bedrijf.

Interview met Frank Steeneken

Integrated Modeling MethodeIMM werd eind jaren negentig van de vorig eeuwontwikkeld door Dr. Dave Ackley. De aanpak isgebaseerd op een systeembenadering. Demethode resulteert in een model van subsystemen,kernprocessen en businessfuncties. Het model laatzien wat een bedrijf doet om zijn functie tevervullen zonder daarbij aan geven hoe het isgeorganiseerd en ingericht.

Elke zakelijke onderneming bestaatuit twee subsystemen. Het ene

subsysteem betrekt hulpbronnenen/of grondstoffen van zijn

leveranciersmarkt en stelt die terbeschikking aan het andere

subsysteem, dat diensten en/ofproducten aan zijn klantenmarkt

levert.

Amuses DREAM16 25

Het is een functioneel model. Het is inrichtings­onafhankelijk, losgekoppeld van organieke en personelestructuur, technologie, huisvesting en andereinrichtingsaspecten. Daarom zijn m.i. Supermarkt Modelzowel als het Basisbedrijfsmodel Terreinbeheeralgemeen toepasbaar binnen de respectievelijkebranches.De website van Dave Ackley toont diverse voorbeeldenvan typen bedrijven c.q zakelijke ondernemingen. Zie hethoofdstuk ‘types of business’ op zijn website. Ik heb geenervaring met de toepassing van IMM binnen een bank ofbij de overheid. Ik heb het gevoel dat het voor delaatstgenoemde minder geschikt is.

Als je voor een nieuw terreinbeheer systeemrequirements op zou moeten stellen, bij welk model zouje dan het beste kunnen beginnen met te analyseren ente doorgronden?

Het Basisbedrijfsmodel Terreinbeheer vormt de basisvoor het organisatieontwerp van een TBO en deinrichting daarvan. Nadat de werkstromen zijn ontworpenkunnen software requirements worden verzameld envastgelegd. Het doorgronden van de werking van eenTBO als één geheel kan al eerder d.w.z. nog voordat hetorganisatieontwerp is opgesteld. Hetzelfde geldt voor hetSupermarkt Model, maar dan voor een supermarktketen.

Hoe kun je via IMM de nadruk leggen op je competitive edge, dat deelvan de keten waarop jij als bedrijf wilt excelleren?

De kernprocessen in IMM corresponderen met delevenscyclus van het business concept van een bedrijf.Per business functie in het model kan inrichtings­onafhankelijk worden beschreven wat moet wordengedaan om het business concept te realiseren.

Vervolgens kan men het bedrijf op een wijze inrichten(organisatie, werkprocessen en technologie) zodat hetals één geheel kan excelleren.

Het model beschrijft de huidige staat. Hoe kun je met behulp van ditmodel nieuwe kansen ontdekken?

Indien nieuwe kansen tot uitdrukking komen in eenwijziging van het business concept dan reïncarneert datconcept als het ware. De businessfuncties in dekernprocessen moeten dan opnieuw worden ingericht ofaangepast. Het model laat dan zien welkebusinessfuncties dat zijn.

Systeembenadering van terreinbeheer

Frank Steeneken is alssenior consultantwerkzaam bij deEntrador ConsultancyGroup.Hij heeft een langjarigeen brede ervaring ophet gebied vanprocesarchitectuur en­ontwerp, businessanalyse enrequirementsengineering in diversesectoren zoalsterreinbeheer, retail,banken, overheid enciviele techniek. Frankheeft zijn opleidingciviele techniek gevolgd aan de (voormalige) HTSWiltzanghlaan te Amsterdam. Frank kan wordenbereikt via steeneken@entrador.com.

DREAMagazine OKTOBER 201626

Ik gebruik UML in mijnwerkAls je ergens van overtuigd bent dan zal je vinden dat je gelijk hebt.Maar wat als iemand het dan totaal niet met je eens is? Dan kan het erwel eens heet aan toe gaan.

In deze rubriek zoeken we de uitersten op. We nemen een stelling,graven ons aan weerszijden in en verzamelen munitie om elkaar mee tebestoken. Dan kan de strijd losbarsten. Het is aan u om een oordeel tevellen: is er een winnaar of eindigt de strijd onbeslist? Deze keer luidt destelling: “Ik gebruik UML in mijn werk”. Bent u het ermee eens? Oftoch niet?

Versus

De afgelopen redactievergadering hadden wij eenverhitte discussie over het nog wel of niet gebruik vanUML in ons werk. Onze meningen waren daaroververdeeld en daarom hebben we dat onderwerp dit keerals stelling genomen.

We hebben veel reacties op deze stelling binnengekregen, waar ook regelmatig bij stond: “dit is geenstelling.” Dat klopt, daar hebben jullie gelijk in. Demeerderheid antwoordde dat hij/zij UML in het werkgebruikt. Slechts een enkeling gebruikt geen UML, maartechnieken als BPMN en ERD. Ons onderzoek heeftuitgewezen welke UML diagrammen het meest in gebruikzijn. Mij verbaasde het in ieder geval niet datactiviteitendiagrammen heel veel gebruikt worden.

Waarom gebruiken we UML?Als we de verschillende reacties bekijken dan zien wedat UML deels gebruikt wordt omdat de klant hetvoorschrijft, maar grotendeels omdat requirementsengineers het een krachtig visualisatiemiddel vinden.

• “Ik zie UML als een mogelijkheid communicatie tefaciliteren – NIET in plaats van de conversatie deinformatie met UML over te dragen. Met dezeinstelling, gebruik ik maar alleen een beperktesubset van de diagrammen (activiteiten ensequence diagrammen vaak, en use­casediagrammen zelden).”

• “Ik gebruik UML in mijn werk. Activity diagrams,Use Case diagrams, beiden omdat ze zijnvoorgeschreven in de template van de klant (enook echt meerwaarde hebben).”

Waarom gebruik je een activiteiten diagram?Wellicht een open deur, maar waarom gebruiken we danmet z’n allen het activiteiten diagram het vaakst?

• “Daarmee kan ik zowel de developers als debusiness een duidelijke weergave van processengeven. De diagrammen zijn eenvoudig te begrijpenen het scheelt een hoop tekst (veel tekst wordt tochniet gelezen).”

• “Om duidelijk te maken hoe het proces loopt”.

ToolsIn de reacties zagen we verschillende opmerkingen overtools die jullie gebruiken om UML diagrammen te maken,hierbij een paar quotes:

• “De ontwerpers hier misbruiken Enterprise Architectals een tekentool, maar gebruiken daardoor 98%van de mogelijkheden niet.”

• “Helaas is er nog geen standaard softwarepakkethiervoor en is het bij elke klant weer anders.”

• “Ook in Visio kun je gemakkelijk activiteitendiagrammen maken, en Visio heb je bijna bij elkeklant tot je beschikking”.

Andere typen diagrammenNiet iedereen gebruikt UML in zijn/haar werk, ensommige requirements engineers gebruiken anderetechnieken naast UML, bijvoorbeeld:

• “Procesontwerp doen we niet in UML, maar inBPMN.”

door Linda Haak ­ van der Spek

Amuses DREAM16 27

• “Ik wil ook het gebruik van Requirements diagramshier uitrollen, maar dat is nog niet gebruikelijk op ditmoment”

• “MindMapping diagram: om vrijer concepten enrelaties te kunnen plaatsen om bijv. een aantalbusiness concepten weer te geven.”

• “Powerpoint plaatjes: als het kleurrijker, losser mag(nadruk meer op het communiceren dan het

ontwerpen/documenteren)“• “Ik ben de laatste tijd vooral bezig met

gegevensmodellen en gebruik hierbij geen UML.Wel heb ik ERD gebruikt.”

Wat ons betreft is de discussie beslecht: UML is nog eenveel gebruikte visualisatietechniek, die je alsrequirements engineer onder de knie moet hebben!

Voor de komende keer kunnen jullie reageren op de stelling:

Als je een plaatje niet uit kunt leggen aan een blindekun je het wel meteen weggooien

Toen we aan Sjir Nijssen vertelden dat het DREAM event over visualiseren ging, stelde hij dat als je een

plaatje niet uit kunt leggen aan een blinde je het plaatje wel meteen kunt weg gooien. Het feit dat je iets tekent

dat je niet in woorden kunt uitleggen, betekent dat je het zelf nog niet goed begrijpt. Toch gebruiken we

tekeningen juist net vaak om dingen te verduidelijken die we in woorden nauwelijks kunnen overbrengen. Is

een tekening krachtiger dan een tekst of juist andersom? Een plaatje zegt meer dan duizend woorden. Geldt

dat voor iedereen of zijn sommige mensen visueel en andere auditief ingesteld? We zijn benieuwd naar jullie

reacties. En als je in beeld gelooft, teken het dan voor ons. dreamagazine@dreamevent.nl

Versus

Amuses DREAM16 28DREAMagazineOKTOBER 2016Dutch Requirements Engineering And Management

.