Whitepaper Process Driven Requirements Engineering
Introductie Veel projecten worstelen met het vaststellen van de probleemstelling en oplossing die daar het beste bij past. Projecten leveren wel goed werkende applicaties op, maar lang niet altijd applicaties die het probleem oplossen. Process Driven Requirements Engineering (hierna: PDRE ) is de methode voor de business om op systematische wijze het projectdoel, het probleem en haar eisen scherp te definiëren. Vertrekpunt hierbij is inzicht in de veranderingen in de business processen, iets wat zowel business als ICT goed begrijpen. De methode sluit naadloos aan op de projectmanagement methoden PRINCE2 TM en Scrum. Hierdoor wordt PDRE herkenbaar in de verschillende projectfasen en kan een verband worden gelegd naar de eigen praktijk. Naast het expliciet maken van de eisen geeft de methode ook handvatten om oplossingen op basis van business requirements te testen. Hierdoor komt niemand aan het eind van de rit voor verrassingen te staan. PDRE bestaat sinds 2008 in boekvorm en kent een herziene versie in 2011. Deze whitepaper heeft als doel de methode in vogelvlucht te beschrijven en een indruk te geven van de voordelen. Onderscheidend vermogen van PDRE Hoewel elk project uniek is, bieden business requirements een prima generiek hulpmiddel om de business behoefte te specificeren, ongeacht of het project groot is of klein, complex of eenvoudig. De wijze waarop business requirements tot stand komen kent echter nog geen geaccepteerde marktstandaard. Diverse ICT-bedrijven, kwaliteitssystemen (CMMi, ISOx, IEEEx), projectmethoden (PRINCE2 TM, Scrum) hebben elk hun eigen aanpak voor requirements engineering. Drie zaken vallen op bij deze aanpakken: Sterke focus op ICT. Eisen worden gespecificeerd vanuit een idee voor een ICT systeem, terwijl er evengoed eisen zijn ten aanzien van bezettingen op afdelingen, besturing van processen, afspraken met partners in de keten, marketingacties et cetera. Projecten creëren met andere woorden bedrijfsbrede veranderingen, waar ICT een onderdeel van uitmaakt. De oplossing als vertrekpunt. Niet het probleem of de gewenste verandering staat centraal, maar vanuit de oplossing worden de requirements bepaald. Hierdoor bestaat het risico dat de oplossing niet of ten dele het probleem oplost. Wisselende diepgang per aanpak. De ene aanpak gaat diep in op het specificeren van requirements maar geeft geen handvatten voor het beheren van requirements. Een andere aanpak is juist sterk gericht op het managen van het requirements proces en biedt juist geen systematiek om requirements te specificeren. PDRE maakt gebruik van de good practices uit eerdergenoemde kwaliteitssystemen en methoden en voegt een aantal hulpmiddelen daaraan toe. De methodiek onderscheidt zich op zes aspecten: 1. De business requirements worden specificeerd vanuit het op te lossen probleem en de gewenste verandering. Het vertrekpunt is dus niet de oplossing. Daarmee is er borging dat het juiste probleem wordt opgelost. 2. De business processen vormen de kapstok om de business requirements aan op te hangen. Processen zijn onafhankelijk van een type project en leidend voor een oplossing. Ze vormen daardoor een ideale context om business requirements uit af te leiden. Bovendien zijn processen herkenbaar voor zowel business als leveranciers. Alle partijen in een project begrijpen processen. Dat maakt de communicatie in projecten eenvoudig. 3. De business requirements zijn bedrijfsbreed en niet beperkt tot ICT veranderingen. 4. De methode beschikt over een beproefd instrument om het rendement van PDRE te meten. 5. De business requirements worden hergebruikt in een testmethodiek, Process Driven Requirements Testing. Dat bespaart projecten tijd bij het opstellen van testcases en biedt ze een manier om systematisch de oplossing te testen op basis van de business requirements. 6. PDRE zorgt voor een centraal overzicht van de samenhang tussen business requirements, processen, stakeholders, oplossingen en testcases. Deze single point of definition bevordert de communicatie in projecten over de herkomst van requirements en waar ze aan gerelateerd zijn. ICT zonder risico Pagina 2 van 7
Waarom Wat Hoe model Een veelvoorkomend aspect bij projecten is dat de oplossing al klaar ligt, terwijl het probleem, het doel en de scope nog niet helder zijn. Achteraf blijkt dat de oplossing niet of slechts ten dele het probleem oplost. Klanten zijn boos, gebruikers zijn teleurgesteld, herstelacties worden op touw gezet en uiteindelijk is het project meer tijd, geld en andere resources kwijt dan was gepland en begroot. Om nog maar te zwijgen over de kans of de juiste mensen dan nog beschikbaar zijn voor de herstelacties. Om dit probleem te voorkomen, hanteert PDRE het Waarom Wat Hoe model. PDRE framework De methode voorziet in een framework met vijf onderdelen, die elk te integreren zijn in de bestaande aanpak voor requirements engineering bij een organisatie. Elk onderdeel kan los van de andere worden ingepast, zonder dat de gehele PDRE methode moet worden geadopteerd. Hierdoor kunnen organisaties doelgericht en beheersbaar verbeteringen aanbrengen. Het laatste wat organisaties willen, is bestaande werkwijzen overhoop halen, good practices overboord gooien en niet meer in control zijn over projecten. Het framework bestaat uit: Stappenplan Stakeholders involvement Van procesanalyse naar requirements Requirements traceability management Learning by doing Afbeelding 1. Waarom-Wat-Hoe model Het Waarom richt zich op het specificeren van het probleem, doel, de scope en betrokken project stakeholders. Het Wat behelst de veranderingen in de processen en de bijbehorende business requirements. Het Hoe omvat de oplossingen met ICT, handmatige procedures, afspraken met ketenpartners, bezettingen op afdelingen et cetera. Bij het in kaart brengen van de business requirements volgt PDRE dit model en legt eerst de focus op het Waarom en bepaalt daarna het Wat. Vervolgens bewaakt de methode de aansluiting tussen het Hoe en de requirements en projectdoelen. Tussen het Waarom, Wat en Hoe borgt PDRE volledige transparantie in de samenhang. Oplossingen zijn gekoppeld aan requirements en requirements hebben een verwijzing naar projectdoelen, op te lossen problemen en stakeholders. Zo kan altijd worden nagegaan wie eigenaar is van een requirement, welk doel of probleem het requirement adresseert en welke oplossing hoort bij welk requirement. In aansluiting op het model beschouwt PDRE requirements engineering als: een proces, dat middels het construeren van eisen de business behoefte definieert, met als doel het oplossen van een probleem, en dat verifieert of de oplossing aansluit op het probleem en de business behoefte. Afbeelding 2. PDRE framework Stappenplan PDRE past een model met stappen toe uit afbeelding 3. Bovenaan staan de constraints, ofwel de kaders en randvoorwaarden voor het project. Requirements moeten passen binnen de constraints, zoals de business principes van de organisatie, wet- en regelgeving, het security beleid en projectbudget. Onder de constraints staan negen stappen, die zijn gemapt op het Waarom Wat Hoe model. Voor het bepalen van de globale requirements in de project startup fase bestaan zes stappen. ICT zonder risico Pagina 3 van 7
Per iteratie, sprint of release wordt vervolgens een geselecteerde set globale requirements SMART gespecificeerd en de oplossing vervolgens gerealiseerd en getest. Dit proces herhaalt zich zolang er iteraties worden opgestart. Afbeelding 3. Stappenplan Stakeholders involvement Een project wordt geïnitieerd door een opdrachtgever die een belang heeft in de gewenste verandering. Echter, een project raakt al snel diverse afdelingen, klantgroepen, leveranciers en andere partijen die naast de opdrachtgever vanuit hun eigen contextrequirements stellen in het project. Het is zaak te onderkennen wie die stakeholders zijn, hen vanaf het begin tot het einde van het project te betrekken en te weten welke eisen ze hebben. Het niet expliciet maken en betrekken van stakeholders heeft als risico dat de verandering niet wordt geaccepteerd, het projectresultaat niet aan de verwachtingen voldoet en het project vroegtijdig sneuvelt. Ten aanzien van stakeholders involvement spelen de volgende aspecten een rol: Welke stakeholders zijn nodig? Wie nemen (minder) actief deel aan het project? Welke mensen vertegenwoordigen een stakeholder? Wat te doen met beperkte tijd bij stakeholders? Hoe gaan workshops met stakeholders in zijn werk en hoe bevraag je ze? Voor een project is het van waarde dat de opdrachtgever een leidende rol speelt in het requirements proces. Hij heeft een groot belang in het project en steekt er geld in. Hij is er bij gebaat dat de juiste requirements boven tafel komen. Om deze redenen neemt de opdrachtgever deel aan de workshops om de veranderingen in de processen te bepalen en de requirements te specificeren. Daarnaast beschikken de vertegenwoordigers van de andere stakeholders over mandaat om namens diens achterban keuzes te maken, visie en ideeën ten aanzien van de gewenste verandering, goede kennis van de betrokken business processen en tijd en de wil om moeite te steken in de workshops. Voor alle workshops geldt dat het een creatief en doelgericht proces is. De deelnemers en hun onderlinge samenwerking bepalen het succes. Dat succes vindt zijn grondslag bij het opvolgen van enkele uitgangspunten: Goed voorbereid beginnen aan de workshop (lezen, bestuderen van beschikbare documenten, heldere verwachting van de workshop, heldere beschrijving van de rol van de deelnemer). Meedenken met andere deelnemers. Openstaan voor ideeën en meningen van anderen. Luisteren naar andermans argumenten. Niet oordelen maar doorvragen. Focus houden op het onderwerp van de workshop. Geen genoegen nemen met half uitgewerkte processen en onduidelijke requirements. Sturen op tijd. Aan het einde van elke workshop samenvatten van de resultaten, besluiten en acties. Afbeelding 4. Workshops Van procesanalyse naar requirements Het derde onderdeel van het framework betreft het bepalen van de requirements vanuit analyse van de processen. Organisaties communiceren middels processen met hun klanten, leveranciers, toezichthouders en andere partijen. Ze creëren producten door processen doelgericht en efficiënt in te richten. ICT zonder risico Pagina 4 van 7
De performance van afdelingen of producten meet een organisatie met behulp van processen. Kortom, met processen en de wijze waarop processen worden uitgevoerd, verdienen of besparen organisaties geld. Projecten brengen veranderingen teweeg in de processen. Ze leiden tot nieuwe, gewijzigde of vervallen processen, andere informatiebehoefte voor processen en tot innovatie in de ondersteuning van processen, zoals ICT systemen. Processen vormen een gemeenschappelijk element dat business en ICT bij elkaar brengt. Het ligt dan ook voor de hand om business requirements op te hangen aan processen. Het benaderen van een verandering vanuit de processen komt in elke stap uit het requirements proces terug. Allerlei vormen van procesanalyse en -tools zijn volledig verweven in de verschillende stappen. De stakeholders worden bijvoorbeeld in de project startup geïdentificeerd met behulp van procesanalyse. Veranderingen in de high level processen worden visueel gemaakt met behulp van functiestroom schema s, zodat inzicht ontstaat in de samenhang tussen processen en overdracht van processen tussen afdelingen en andere partijen. Daarmee is de basis gelegd voor het bepalen van de globale requirements. De high level processen en hun in- en output vormen als het ware een kapstok waaraan globale requirements worden gekoppeld. Elk proces en elke in- en output kent één of meer globale requirements. Afbeelding 5. Koppeling globale requirements aan processen, input en output PDRE past ook na het bepalen van de globale requirements een procestool toe, wanneer de oplossingen bij de requirements in beeld komen. Om de best passende oplossing te valideren op juistheid en volledigheid vindt een processimulatie plaats. Een processimulatie bootst in een rollenspel het to be proces na. De resultaten van de simulatie kunnen leiden tot bijstellingen in het nieuwe proces. Na de project startup volgt een aantal iteraties. Bij elke iteratie wordt een aantal high level processen verder uitgediept naar detail processen en business use cases (flows door de detail processen heen). De detail processen dienen als context voor de detail requirements. Elke proces en elke in- en output van een proces kent één of meer detail requirements. Afbeelding 6. Koppeling requirements aan projectfasen Requirements traceability management Gedurende een project is er in het projectteam behoefte aan inzicht welke requirements in welke iteraties zijn gepland, wat de status is van bepaalde requirements, welke requirements bij welke stakeholders horen, welke processen wel of nauwelijks requirements kennen, welke requirements aan welke testcases zijn gekoppeld, et cetera. Maar ook buiten het project bestaat behoefte aan inzicht in de producten die het project oplevert. Bijvoorbeeld een afdeling Risk Management wil met projectaudits implementatierisico s inzichtelijk maken en onderzoekt hoe gewijzigde processen zijn getest. Of een afdeling Functioneel Beheer wil weten welke testcases bij welke requirements horen. Kortom, er bestaat binnen en buiten een project een wens voor transparantie en overzicht in de producten van een project en hun samenhang. PDRE voorziet in een basisstructuur voor requirements traceability, die uitbreidbaar is naar extra elementen en verbanden. In basis bestaat de structuur uit drie componenten: Elementen, zoals projecten, stakeholders, requirements, processen, oplossingen, testcases. Kenmerken per element, bijvoorbeeld een requirement heeft als kenmerken een nummer, omschrijving, status, prioriteit, versie. ICT zonder risico Pagina 5 van 7
Relaties tussen elementen, bijvoorbeeld een stakeholder hoort bij een requirement, een requirement hoort bij een proces of een testcase hoort bij een requirement. De basisstructuur is een model dat in diverse in de markt verkrijgbare tools geconfigureerd worden. De tool (ook wel RTM tool genoemd) is bedoeld voor een individueel project, maar bewijst ook zijn dienst over de projecten heen. Requirements eindigen namelijk niet bij het afsluiten van een project, maar hebben een levenscyclus die over de levenscycli van projecten heengaan. Daarmee wordt de tool een repository met informatie over processen, requirements en andere business expertise, die bij elk nieuw project wordt gebruikt. Learning by doing Een requirements proces staat niet in één keer gelijk goed. Praktische toepassing van PDRE leidt tot nieuwe inzichten en verbeteringen in het requirements proces. De aandacht voor learning by doing ligt op het meten van het requirements proces en het sturen van verbeteringen. Hiervoor is een instrumentarium, dat bestaat uit: KPI dashboard Retrospectives Analyse van review en testbevindingen Afbeelding 7 illustreert een deel van het dashboard. Het geeft zicht op de mate van efficiëntie van het requirements proces bij lopende en reeds afgeronde projecten. De grafieken geven de herstelkosten van requirement defects weer, het aantal requirements in een project dat niet meer dan drie versies kent en het gemiddeld aantal bestede uren per requirement. Afbeelding 7. KPI dashboard Door projecten en hun performance visueel naast elkaar te leggen, kunnen lopende projecten tussentijds bijsturen indien nodig en bij andere projecten nagaan wat zij van hen kunnen leren en eventueel overnemen. Bovendien kan een dashboard, dat steeds meer project performances bevat, nieuw op te starten projecten helpen doelen te stellen ten aanzien van het requirements proces. Ook geeft het input om te bepalen hoeveel tijd nodig is om requirements te specificeren. In veel projecten is het een standaard protocol om testbevindingen en bevindingen uit reviews vast te leggen. Doorgaans hebben deze administraties als doel om het herstel van bevindingen te volgen en bewaken. Echter, een analyse op deze bevindingen levert zeer waardevolle informatie op over de oorzaak van bevindingen en wanneer in een project de fout is ontstaan en gevonden. Door deze informatie in verband te brengen met factoren voor herstelkosten en in projecten gehanteerde uurtarieven, levert een bevindingen analyse op een feitelijke manier inzicht in de efficiëntie van het requirements proces. Deze informatie wordt teruggesluisd naar het KPI dashboard, zodat de organisatie verbeteracties kan doorvoeren in lopende en nieuwe projecten. ICT zonder risico Pagina 6 van 7
Process Driven Requirements Testing Een acceptatietest vindt plaats aan het einde van een iteratie en heeft als doel het vaststellen of een oplossing (ICT systemen en alle andere oplossingen die een project realiseert) voldoet aan de business requirements en to be processen. Process Driven Requirements Testing (hierna: PDRT) is een aanpak die bij acceptatietesten wordt toegepast en is een add-on op bestaande testmethoden, zoals ISTQB en TMap NEXT. Omdat deze methoden noch technieken kennen om vanuit processen en business requirements een risicoanalyse op te stellen noch handvatten aanreiken om testcases te maken op basis van business requirements, biedt PDRT de benodigde aanvullingen. beschrijving, vormt geen testbasis voor een acceptatietest. Deze documenten beschrijven de oplossing en worden gebruikt bij een systeem(keten)test, die vaststelt of de oplossing werkt conform de documentatie. Op basis van de business requirements en to be processen creëert PDRT testcases. Bij het opstellen van testgevallen worden de requirements en processen hergebruikt, waardoor tijd wordt bespaard. Slim met tijd omgaan en gebruikmaken van de business waar zij de meeste toegevoegde waarde biedt, zijn belangrijke aspecten van PDRT. Acceptatietesten legt een groot beslag op de business. Testen kost hen veel tijd. Tijd die schaars is en ten koste gaat van hun dagelijkse lijnactiviteiten. De business wordt daarom bij PDRT met name betrokken bij de risicoanalyse van de test en het opstellen van testcases. Het uitvoeren van acceptatietesten kan door de gestructureerde opzet van de testcases eenvoudig worden uitbesteed aan professionele testers. Meer informatie over PDRT staat in de whitepaper PDRT die te vinden is op de website van Qquest. Afbeelding 8. PDRT aan het einde van een iteratie De testbasis voor een acceptatietest is de business behoefte. De van de business behoefte afgeleide systeemdocumentatie, zoals een functioneel ontwerp of technische Ter afsluiting Deze whitepaper kan niet alles vertellen over PDRE. Het is bedoeld om een indruk te geven van de methode. Uitgebreide informatie, een case en checklists staan in het boek Process Driven Requirements Engineering, dat u via www.qquest.nl kunt bestellen. ICT zonder risico Pagina 7 van 7