Requirements professionaliseren

Transcriptie

1 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

2 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

3 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

4 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 tekenen om meer overzicht te krijgen. De recente OMG standaard BPMN 1 biedt een goede standaardvorm van procesdiagrammen. Voor het specificeren van termen, definities en bedrijfsregels biedt OMG sinds 2008 de standaard SBVR 2. 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 Organisations) ontologie toe te passen zoals ontwikkeld door Prof. J.G. Dietz. 3 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: 2 Zie: Versie 1.1 is in een vergevorderd stadium. 3 Zie: USoft Whitepaper pag. 4 van 6

5 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

6 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 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) [email protected] Website: USoft Whitepaper pag. 6 van 6