Whitepaper PDRE versie 1.7

Whitepaper
Process Driven
Requirements Engineering®
Process Driven Requirements Engineering
®
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.
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
TM
projectmanagement methoden PRINCE2 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), projectTM
methoden (PRINCE2 , 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
®
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
Process Driven Requirements Engineering
®
Waarom–Wat–Hoe model
PDRE® framework
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.
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.
Om dit probleem te voorkomen, hanteert
®
PDRE het Waarom–Wat–Hoe model.
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
Process Driven Requirements Engineering
®
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
Process Driven Requirements Engineering
®
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
Process Driven Requirements Engineering
®
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 Engineering
®
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.
Ter afsluiting
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
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