Requirements professionaliseren

USoft Whitepaper
Requirements professionaliseren
“Zonder eenduidige en consistente business requirements zal het een organisatie niet lukken om
wendbaar te worden bij het uitrollen van software of het realiseren van procesverbeteringen.”
Bedrijven moeten steeds sneller inspelen op veranderende marktomstandigheden. Organisaties die zich in
eenzelfde keten bevinden gaan steeds meer met elkaar samenwerken. Systemen moeten hierop worden
aangepast. Nieuwe systemen moeten worden geïmplementeerd. Het opstellen van de juiste requirements is
daarbij van cruciaal belang. Hoe zorgen we dat requirements in heldere taal worden beschreven, dat er
samenhang met architectuur en processen ontstaat, en dat organisaties wendbaarder worden bij het
doorvoeren van wijzigingen? Dit whitepaper geeft managers, requirementsspecialisten, enterprise-architecten
en business-analisten handvatten om de kwaliteit van het opstellen, vastleggen en beheren van requirements te
verbeteren.
Een paradoxale managementvisie
Enkele conclusies over het omgaan met requirements zijn:




71% van de fouten in projecten zijn het gevolg van slechte requirements (Forrester).
40%-50% van de projectinspanning is herstelwerk door slechte requirements (Wiegers).
Fouten oplossen in de requirementsfase is 10 keer zo goedkoop dan in de bouwfase (Boehm).
Projecten worden door slechte requirements 70% groter (Gartner).
Dit zijn bijna willekeurige voorbeelden. Dit soort feiten zijn overal te vinden en worden inmiddels algemeen
onderkend. Daarmee is ook het belang van requirements voor IT-systemen duidelijk. Die bepalen of een
organisatie zich snel en succesvol zal kunnen aanpassen aan nieuwe marktomstandigheden. Ze mogen geen ruimte
laten voor verschillende interpretaties. Dat leidt tot verkeerde aannamen, planning- en budgetoverschrijdingen, en
onbedoelde functionaliteit in IT-systemen.
Waarom besteden managers dan toch zo weinig aandacht aan requirements? Waarom stellen analisten nog steeds
zwaarlijvige documenten op voor procesveranderingen, aanbestedingen of applicaties? Waarom zijn termen,
definities en procedures daarin niet consistent beschreven? En waarom schrijven we requirements nog steeds met
behulp van algemene kantoorsoftware zoals MS Word of MS Excel?
Het is een paradox. De algemene overtuiging bestaat dat requirements belangrijk zijn. Maar in de praktijk worden
er weinig maatregelen getroffen om beter met requirements om te gaan. Deels is dat een latent probleem. Men
h f “ l j zo gewerkt”. Het management wordt niet direct betrokken bij requirements. Een gevoel van urgentie
en prioriteit ontbreekt.
USoft Whitepaper
pag. 1 van 6
USoft Whitepaper
Wat staat er op het spel ?
U kunt het professionaliseren van requirements blijven uitstellen. Dan blijft uw Total Cost of Ownership (TCO)
hoger dan nodig is. Ook blijft uw time-to-market dan relatief lang. Dat heeft een aantal aanwijsbare oorzaken.
Onflexibele processen
Elk bedrijf heeft er behoefte aan om zijn processen doelmatig in te richten. Alleen dan kunnen die processen, via
een aantal aanpassingsronden, worden geoptimaliseerd. Veel bedrijfsprocessen veranderen regelmatig,
bijvoorbeeld door uitbesteding. Om die veranderingen in de hand te houden is goede, accurate en bijgewerkte
documentatie noodzakelijk. Die maakt het ook mogelijk om de processen te toetsen aan veranderende wet- en
regelgeving en aan normen die een organisatie zichzelf heeft opgelegd. In de praktijk zien we dat deze vorm van
beheer ontbreekt, waardoor processen onflexibel zijn.
Verouderde IT-systemen blijven remmend werken
Organisaties hebben vaak te maken met verouderde IT-systemen. Dat geldt voor veel financiële instellingen,
overheids- en zorgorganisaties. Kennis is in die systemen alleen vervat in ingewikkelde technische code. Uit angst
voor ongewenste gevolgen durft men die niet meer aan te passen. In plaats daarvan worden ‘h j - w j ’
constructies bedacht om de software toch te kunnen blijven gebruiken. Hierdoor is het moeilijk in te schatten wat
er zal gebeuren als het systeem wordt vervangen.
Veel organisaties maken de fout om zich dan maar helemaal niet meer in die systemen te verdiepen, maar er
“ h
”
. Dat leidt op den duur tot verborgen kosten en gebrek aan wendbaarheid.
Onvoldoende begrip tussen business en IT
Hoe gaat het vaak in de praktijk? De business wil iets. IT denkt te begrijpen wat het is, en gaat aan de slag. Maar
het eindresultaat is niet wat de business wilde.
IT'ers zijn niet de medewerkers die de bedrijfsvoering het beste kennen. Toch laten we softwareprojecten in de
praktijk bijna geheel door technische mensen uitvoeren. Aan de expertise van een business-analist, namelijk het
vakkundig in kaart brengen van zakelijke eisen met begrip voor technische mogelijkheden en barrières, wordt dan
voorbijgegaan.
Omslachtige werkwijze en producten
Requirementsproducten zijn vaak lijvige documenten met functionele en technische specificaties. Weliswaar
worden Agile methoden zoals Scrum steeds vaker toegepast. Daarbij is het schrijven van zulke documenten niet
meer aan de orde. Maar “ g l ” richt zich vooral op het bouwproces. Het management, organisatiedeskundigen,
procesontwerpers en beheerders zijn daar niet direct bij betrokken. Zij moeten afzonderlijk worden geraadpleegd
en ingelicht. Zelfs als de requirements duidelijk zijn voor de bouwers, moeten toch nog uitgebreide beschrijvingen
speciaal voor testers en documenteerders worden gemaakt.
Specificaties die niet herbruikbaar zijn
U kunt requirements blijven schrijven als onderdeel van een specifiek IT-project. Maar dan is het resultaat van al
die inspanning niet herbruikbaar in andere situaties, zoals in vervolgprojecten. Een modernere aanpak van
requirements kan dat hergebruik wèl mogelijk maken.
USoft Whitepaper
pag. 2 van 6
USoft Whitepaper
Wat is de oplossing?
Samengevat vindt iedereen requirements belangrijk, maar zijn er te weinig initiatieven om ze te verbeteren.
Dat leidt tot hoge Total Cost of Ownership en lange time-to-market. De oplossing is om:



Verworvenheden van requirementsanalyse te benutten.
Requirementsanalyse naar een hoger plan te tillen.
Toolgebruik te professionaliseren.
Verworvenheden van requirementsanalyse benutten
Moderne requirementsanalyse is een volwassen vakgebied. Het biedt essentiële verworvenheden die breed
gedeeld worden door bijna alle gangbare methodieken, zoals:




Gedegen aandeelhoudersanalyse, zodat geen belangen vergeten worden.
Use case analyses. Zij bieden een goed overzicht van de gewenste functionaliteit, en vooral van de
achterliggende redenen daarvoor.
De behoeften van de organisatie zijn het uitgangspunt. Ze worden losgekoppeld van mogelijke
oplossingen. De vraag staat centraal, de technische ideeën over oplossingen komen later.
Er wordt voldoende aandacht besteed aan niet-functionele eisen en wensen. In het verleden werden
niet-functionele eisen vaak te laat onderkend.
Requirementsanalyse naar een hoger plan tillen
Requirementsanalyse heeft ook haar beperkingen. Die zijn vooral gelegen in het centraal stellen van het beoogde
resultaat. Dat is veelal een stuk nieuwe of vernieuwde software. De analyse is beperkt tot een specifiek IT-project,
waaraan een team, budget en tijdsbestek zijn toegewezen. Technieken als aandeelhoudersanalyse en use case
beschrijving nemen die projectgebondenheid als uitgangspunt.
Requirements zijn daarom meestal niet herbruikbaar buiten een specifiek IT-project, of ze zijn het wel maar
worden om project-organisatorische redenen niet hergebruikt. Het komt regelmatig voor dat medewerkers bij
interviews voor een vervolgproject opnieuw moeten vertellen wat ze 6 maanden geleden ook al hebben uitgelegd.
Agile methodieken zijn verbluffend efficiënt in het overdragen van al wel onderkende, maar nog niet
geprioriteerde requirements naar een volgende opleverfase: de product backlog van Scrum is het bekendste
voorbeeld. Maar dit mechanisme beperkt zich tot, inderdaad, een backlog: het zich blijven herinneren van nog niet
vervulde IT-wensen. Minstens zo interessant voor hergebruik is de geïnventariseerde bedrijfskennis. Die overstijgt
de analyse van IT-requirements. Zij is onafhankelijk van wel of niet gerealiseerde software.
Professionaliseren door een breder kader van bedrijfskennis te omarmen
Requirementsanalyse kan op een hoger plan gebracht worden door requirements (wat moet er gebouwd
worden?) te combineren met een breder kader van omringende bedrijfskennis. Bedrijfskennis zoals die door goede
analisten wordt geïnventariseerd omvat namelijk ook:


Een vocabulaire van termen en definities die het bedrijf hanteert in haar dagelijkse praktijk.
Bedrijfsregels.
USoft Whitepaper
pag. 3 van 6
USoft Whitepaper


Algoritmen (rekenmodellen, beslisbomen, beslistabellen). Algoritmen zijn structuren van met elkaar
samenhangende bedrijfsregels.
Proces-ontwerpen, zoals bijvoorbeeld gevisualiseerd in BPMN diagrammen.
Al deze aspecten zijn verbonden met IT-requirements in nauwere zin. Als het goed is, gebruikt een IT-requirement
over een prijsberekening de bedrijfsterm incidentele kortingsregel op dezelfde manier (met dezelfde definitie dus)
als het bedrijf zèlf. Door zo'n definitie, een essentieel stukje bedrijfskennis, los te zingen van een specifiek
IT-project en afzonderlijk (maar wel in samenhang met de lijst van IT-requirements) aan te bieden wordt een
eenduidig gebruik van de term incidentele kortingsregel enorm bevorderd. Hergebruik over IT-projecten heen,
maar ook hergebruik door een groter publiek dan alleen software-ontwikkelaars.
Professionaliseren door gebruik te maken van aanvullende methodieken
Door requirementsanalyse in een breder kader te plaatsen, kan deze profiteren van de voordelen van aanvullende
methodieken. Dat zijn vooral methodieken op het gebied van bedrijfsmodellering.
Op dit moment is het al gangbaar in de requirementswereld dat analisten een vorm van procesdiagrammen
1
tekenen om meer overzicht te krijgen. De recente OMG standaard BPMN biedt een goede standaardvorm van
procesdiagrammen.
2
Voor het specificeren van termen, definities en bedrijfsregels biedt OMG sinds 2008 de standaard SBVR . Een
verwante methodiek in Nederland is CogNIAM van PNA Group. Het toepassen van CogNIAM is een interactief
proces waarbij de domeindeskundigen samenwerken met analisten. Op basis van de beschikbare kennis stellen ze
een volledig geïntegreerd kennismodel op. Daarin wordt de volledige samenhang van processen,
gegevensstructuur, bedrijfsregels en begrippen beschreven. USoft werkt samen met de PNA Group. De methode
CogNIAM is geïntegreerd met de requirementssoftware URequire Studio van USoft.
PNA Group licht hun begrip bedrijfskennis als volgt toe: "De kennis binnen uw organisatie bevindt zich grotendeels
in de hoofden van uw medewerkers, maar ook in papieren documenten, digitale bestanden, systemen en
applicaties. Hierdoor is het belangrijkste kapitaal van uw organisatie, het kennis-kapitaal, niet op een efficiënte
manier inzetbaar en functioneert de organisatie niet optimaal. De CogNIAM aanpak wordt ingezet om deze kennis
boven water te krijgen en te structureren. Kennis wordt in volledige samenhang benaderd en op een voor iedereen
begrijpelijke en toegankelijke manier binnen de organisatie beschikbaar gesteld. Dit geeft u de volledige controle
over het kenniskapitaal, dat binnen de organisatie productief en efficiënt inzetbaar wordt."
Goed onderbouwde bedrijfsmodellering wordt ook bereikt door de DEMO (Dynamic Essential Modelling for
3
Organisations) ontologie toe te passen zoals ontwikkeld door Prof. J.G. Dietz. Deze ontologie gaat uit van
transacties die actoren met elkaar aangaan. Deze transacties zijn de hoeksteen van de bedrijfsvoering. Alle
processen, objecten en regels worden in het leven geroepen als gevolg van transacties. Ze krijgen een plaats in een
overkoepelende structuur. Hoe die structuur eruit ziet wordt volledig bepaald door de soorten transacties die
plaatsvinden in het bedrijf.
1
Zie: http://www.omg.org/spec/BPMN/2.0/.
Zie: http://www.omg.org/spec/SBVR/1.0/. Versie 1.1 is in een vergevorderd stadium.
3
Zie: http://www.demo.nl.
2
USoft Whitepaper
pag. 4 van 6
USoft Whitepaper
Professionaliseren van toolgebruik
Helaas gebruiken vele analisten nog steeds simpel gereedschap dat hen slecht ondersteunt bij het formuleren,
vastleggen, uitdragen en hergebruiken van requirements.
Gespecialiseerd gereedschap voor de requirementsfase heeft vele voordelen:
Centraal beheer





Kennis kan expliciet en centraal worden bewaard en ontsloten.
Dezelfde (basis)requirements kunnen bij meerdere projecten worden hergebruikt.
Sjablonen bevorderen eenvormigheid, vergelijkbaarheid en combineerbaarheid van requirements.
Informatie uit meerdere bronnen (zoals documenten, interviews en workshops) kan goed worden
gecombineerd.
Meerdere actoren kunnen parallel aan requirements voor hetzelfde project werken, en op elkaars input
voortbouwen.
Kwaliteitsbewaking



De juistheid van requirements kan gemakkelijker worden gevalideerd.
De consistentie van requirements kan makkelijker worden gecheckt. Met name het risico op verschillende,
nét uiteenlopende versies van eenzelfde wens of eis wordt sterk verminderd.
De volledigheid van requirements kan door geen enkel tool gegarandeerd worden, maar lacunes treden
wel veel sneller aan het licht.
Requirementsmanagement




Meta-gegevens over een requirement, zoals identificatie, versie, prioriteit, status, bron, eigenaar, datum
gevalideerd, kunnen veel traceerbaarder worden aangebracht dan in verhalende documenten.
Relaties tussen requirements, processen, informatie, architectuur en applicaties worden expliciet.
Veranderingen in requirements kunnen makkelijker worden gevolgd.
De impact van specifieke wijzigingen kan beter vooraf worden bepaald.
Koppeling


Het gereedschap kan gekoppeld worden aan productietools voor projectbewaking bij systeembouw,
testmanagement, en bevindingenbeheer. Voorbeelden zijn JIRA en TeamWork Foundation. Dit maakt het
beheer van het totale kwaliteitsproces efficiënter en eenvoudiger.
De requirementsanalyse kan expliciet gekoppeld worden aan aanvullende modelleringstechnieken zoals
bijvoorbeeld BPMN, SBVR, CogNIAM, of de DEMO enterprise ontology.
USoft Whitepaper
pag. 5 van 6
USoft Whitepaper
Hoe kan URequire Studio u helpen?
URequire Studio is een software applicatie die u in staat stelt om uiteenlopende vormen van requirements en
bedrijfskennis op te stellen, centraal te bewaren, open te stellen aan de juiste aandeelhouders, en steeds opnieuw
te gebruiken.


Centraal staan formuleringen in natuurlijke taal: termen, definities, bedrijfsregels volgens SBVR, en
atomaire requirement statements zoals die gebruikelijk zijn in de meeste requirementanalyse technieken.
In combinatie daarmee kunnen procesflowdiagrammen volgens BPMN 2.0, DEMO constructiediagrammen,
en PRONTO transactiediagrammen (een variant op de DEMO diagramtechniek ontwikkeld door Sogeti)
worden getekend en opgeslagen; daarin gebruikte termen krijgen automatische kruisverwijzingen naar de
requirements in taalvorm.
URequire Studio maakt het beheren en verbeteren van requirements tot een overzichtelijke taak. Door
bedrijfsinformatie als vocabulaire, bedrijfsregels, procesverloop, rollen en verantwoordelijkheden centraal vast te
leggen is het niet nodig om het wiel voor ieder project opnieuw uit te vinden. Requirements worden zichtbaar en
verifieerbaar, en kunnen eenvoudig worden overgedragen aan de mensen die ermee gaan werken.
URequire is geschikt voor informatiemanagers, requirementsspecialisten, enterprise-architecten, business
analisten en software ontwerpers die requirements eenduidig en efficiënt willen vastleggen in samenhang met
processen en architectuur.
Over USoft
USoft dicht het gat tussen Business en IT. Dankzij USoft kunnen organisaties architectuur, business processes en
requirements in samenhang beschrijven en beheren op een consistent en geïntegreerde manier. De software
wordt gebruikt door meer dan 10.000 gebruikers wereldwijd in organisaties zoals Achmea, AgentschapNL,
AkerSolutions, Eno, ITV, KLM, and Sandd.
Heeft u vragen over dit whitepaper of wilt u hierover verder van gedachten wisselen? Neemt u dan s.v.p.
contact op met Maarten Witvliet of Robin van der Breggen:



Tel: +31-(0)35 699 0 699
Email: [email protected]
Website: www.usoft.com
USoft Whitepaper
pag. 6 van 6