Process Driven Requirements Engineering PDRE · 2012. 10. 2. · Requirements Engineering PDRE ......

1

Toegepaste Informatica

Bachelorproef

Process Driven Requirements Engineering

PDRE ®

[email protected]

PDRE is een gedeponeerd merk van Qquest - http://www.qquest.nl

mailto:[email protected]

http://www.qquest.nl/

Copyright © 2009-2012 - Green10 2

RequirementsElicitation

Analyse

System Design

Object Design

GedetailleerdeDesign

Implementatie

Unit Testen

Integratietesten

Systeemtesten

UserAcceptatietesten

WerkendSysteem

Copyright © 2012 - Green10 3

Span de kar niet voor het paard

RF foto's Dreamstime

ProbleemDoel

ScopeOplossing

Bron: http://www.qquest.nl/ en "Process Driven Requirements Engineering", R. Harreman, Qquest 2011 4

Waarom – Wat – Hoe Model

Waarom Wat Hoe



Waarom● Welk probleem wil men oplossen?

● Wat zijn de doelstellingen van het project?

● Wat is de scope van het project?

● Wie zijn de stakeholders?



Wat

Gegeven het waarom

● Wat zijn de (veranderingen aan de) processen?

● Wat zijn de requirements die daarbij horen?



HoeHet hoe omvat:

● ICT-oplossingen

● handmatige procedures

● afspraken met ketenpartners,

● bezettingen op afdelingen

● enzovoort



Waarom Wat Hoe

OplossingenProcessen enrequirements

ProbleemDoelstellingenStakeholders

Ook: oplossingen zijn er voor requirements,die voortvloeien uit de probleemstelling


Requirements engineering is dus ...

een proces

● dat middels het construeren van eisen (requirements)

● 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


Eisen aan requirements engineering


Eisen aan requirements engineering● Juistheid

● Correct geprioritiseerd● Eenduidig te begrijpen door de probleemstellers en de oplossers

● Maakbaarheid● Requirements zijn te vertalen naar realistische oplossingen met accepabele kosten

● Beheersbaarheid● Versiebeheer + bijhouden van rationale achter beslissingen● Requirement traceerbaar naar projecten, processen, stakeholders, oplossingen,

testscripts● Volledigheid

● Volledig genoeg om het probleem kwalitatief op te lossen● Met identificatie en actieve betrokkenheid van alle relevante stakeholders

● Efficiëntie/Effectiviteit● Maximum 3u per requirement, ● 5% requirement defects en 5% projectkosten voor herstel requirement defects


Definitie van een requirement volgens PDRE

PDRE beschouwt een requirement als

● een eis aan de werking van een proces of

● een eis aan de input of output van een proces


Requirements moeten uiteindelijk SMART zijn

Specifiek,

Meetbaar/testbaar,

Acceptabel,

Realistisch en

Tijdsgebonden



Soorten requirements

Detail requirement

Functioneel requirement

Niet Functioneel requirement

Globaal requirement

● Functionele requirements (80%) vertellen WAT de eisen zijn aan de werking van een proces, de inputs of outputs

● Niet-functionele requirements (20%) vertellen WELKE kwaliteitseisen een proces, input of output moet hebben

● Zie ISO 9126 en Checklist D in het boek

Bron: http://www.smartest.nl/verdieping/kwaliteitsmodellen/iso9126 15

Niet-functionele requirements volgens ISO 9126

Bron: Wikipedia 16

ISO 25010 vervangt ISO 9126


Globale vs Detail requirements


Voorbeelden van 4 soorten requirements


Constraints

Constraints vormen kaders en randvoorwaarden waarbinnen requirements van toepassing zijn.

Constraints zijn niet onderhandelbaar

Functionele requirements

Niet functionele requirements

Businessconstraints

Projectconstraints

Technischeconstraints

Oplossingsconstraints


PDRE Framework

Bron: Project-management volgens Prince2 – Peter Janssen

Prince2 procesmodel

START

ITERATIES


De ontwikkelingscyclus onder Scrum

Bron: http://www.mountaingoatsoftware.com

STARTITERATIES

http://www.mountaingoatsoftware.com/


PDRE is een plug-in voor Prince2 en/of Scrum

● Analyseren van het probleem, doel en scopevòòrdat een oplossing wordt gekozen

● Identificeren van stakeholderszodat belangrijke stakeholders niet gemist worden

● Borgen dat de oplossing past in de business processen

● Specificeren van bedrijfsbrede requirements die niet alleen op de uiteindelijke ICT oplossing gericht zijn

● Traceability tussen requirements, processen, stakholders, oplossingen en testgevallen + overzicht van deze samenhang

● Integreren van requirements engineering met acceptatietesten (Process Driven Requirements Testing - PDRT)


Stappenplan

Waarom Wat Hoe

Constraints

1. definiëren doel /

scope /stakeholders

2. analyserenglobaleproces

verandering

3. specifiërenglobale

requirements

4. bewakentraceability

requirementsvs oplosssingSTART

ITERATIE

5. validerenprocessen enrequirements obv prototype

6. prioriterenglobale

requirements

7 analyserendetail

procesverandering

8. specifiërendetail

requirements

9. bewakentraceabilityreqs vs oplen PDRT


Stap 1. Definiëren projectdoel, scope en stakeholders

Waarom Wat Hoe

START

ITERATIE

Constraints


scope /stakeholders


Stap 1. Definiëren projectdoel, scope en stakeholders

● Opdrachtgever, projectmanager en business analist komen bij elkaar

● Input = projectmandaat

● Werkzaamheden en outputs (zie ook Checklist A – intake opdracht)● inventariseren constraints

● aanscherpen probleemstelling, projectdoel en scope

● nagaan welke afdelingen en externe partijen een belang hebben aan de verandering → stakeholders

● Hulpmiddelen● visgraatdiagram, walk the process, gegevensanalyse, context mapping,

COPAFIJTH (Commercieel, Organisatie, Personeel, Administratie, Financiën, Informatie, Juridisch, Technologie en Huisvesting) SIPOC (Supplier, Inputs, Processes, Outputs, Customers)

Copyright © 2010-2012 - Green10 27

Vereisten verzamelen: een probleem van communicatie

Klanten, Gebruikers

Domeinexperten

Ontwikkelaars



Stap 2. Analyseren globale procesverandering

Waarom Wat Hoe

START

ITERATIE

Constraints


verandering


Stap 2. Analyseren globale procesverandering● De projectmanager organiseert een kick-off vergadering, met

● opdrachtgever, projectmanager en business analist● de vertegenwoordigers van de geïdentificeerde stakeholders● een vertegenwoordiger van ICT

● Na de kick-off volgen een reeks workshops met opdrachtgever en die stakeholders wiens processen direct geraakt worden door het project. De business analist leidt deze workshops

● Input = projectdoel, probleemstelling, scope, stakeholder info● Doel van de kick-off

● Communicatiemiddel = symbolisch begin van het project● De reeds verzamelde informatie wordt toegelicht en eventueel bijgestuurd

● Output van de kick-off en de workshops● Definitieve probleem- en doelstelling van het project● Overzicht van de high level processen die geraakt worden● Functiestroomschema's (of BPMN-diagrammen) van de high level to-be processen● Een set van business-events met betrekking tot de to-be processen



Hulpmiddel 1 - Proceshiërarchie

Procesketen (over ≠ organisaties)

Bedrijfsproces (over ≠ afdelingen)

Werkproces (in één afdeling)

Activiteit

Afd. A Afd. B Afd. C

Org. X

Afd. A Afd. B Afd. C

Org. Y



Hulpmiddel 1 - Proceshiërarchie

Leverancier Organisatie Klant

Kernprocessen

Supportprocessen

Governanceprocessen

Inkopen Verkopen Leveren Incasseren

Prospec-teren Offreren Bestellen

Identificerenklant

Selecterenproduct

Bevestigen

Bedrijfsproces

Werkproces

Activiteit(in deze stap nog niet)

START

ITERATIES



Hulpmiddel 2 – Business events en functiestroom schema's

● Business event: gebeurtenis geïnitieerd door een klant, leverancier, afdeling, datum of tijdstip

● De voor het project relevante business events dienen geïdentificeerd

● De organisatie reageert op deze events met een to-be bedrijfsproces of werkproces

● PDRE beschrijft de processen in functiestroom schema's met swimlanes. U zult natuurlijk BPMN gebruiken

BusinessEvent

Procesmet inputen output




Klant AfdelingReserveringen

Leverancier AfdelingDebiteuren

Business EventKlant boekt

vakantie

Input

Boeken

Output

Input

Goedkeuren

Output

BevestigenResultaatOntvangstbevestiging

ResultaatOntvangstbevestiging



Hulpmiddel 3 – Risico-analyse

● FMEA (Failure Mode and Effect Analysis) wordt gebruikt

● Wat kan er fout gaan? (en hoe gaan we mitigeren? → requirements)

● Wat kan er fout gaan in het proces

● Wat zijn de gevolgen als de fout optreedt?

● Hoe ernstig zijn de gevolgen?

● Wat zijn de oorzaken van de fout en de kans van optreden?

● Hoe kan een fout worden ontdekt?

● Welke fouten moeten worden voorkomen met welke prioriteit?



Hulpmiddel 4 – Checklist vragen per proces (appendix B)● Eisen aan het to-be procesmodel

● Denk niet aan de as-is processen, die kunnen minder goed zijnDenk vanuit business doelstellingen en business principes

● Wat is de toegevoegde waarde voor de (interne) klant van het procesAls die er niet is, is het proces (en de requirements) in feite overbodig

● Een proces heeft een proceseigenaar die zelf meedoet aan het ontwerpen van de to-be processen (of is anderzijds vertegenwoordigd)

● Processen worden gemodelleerd. De input en output wordt gespecificeerd

● Vragenlijst zie appendix B: W- en H-vragen over proces en I/O

● Niet zelden worden de as-is-processen serieus vereenvoudigd


Stap 3. Specifiëren globale requirements

Waarom Wat Hoe

START

ITERATIE

Constraints


requirements

Stappen 2 en 3 gebeuren in de praktijk gelijktijdig en iteratief


Stap 3. Specifiëren globale requirements● Stappen 2 en 3 gebeuren in de workshops met de opdrachtgever en die

stakeholders wiens processen direct geraakt worden door het project. De business analist leidt deze workshops● De discussie gaat over processen en tegelijk leidt de gedachtengang tot

requirements en andersom: requirements scherpen processen aan

● Doel: Bepalen en specificeren van de globale requirements● Input: business events en functiestroomschema's● Output

● Een set functionele - en niet-functionele globale requirements (nog niet SMART)● Samenhang tussen requirements en bedrijfs- en werkprocessen

● Hulpmiddelen● Checklist vragen per proces (bijlage B)● Checklist opstellen requirements (bijlage C)● Checlist niet functionele requirements (bijlage D)● Checklist rapportage requirements (bijlage E)



● Stel ook volgende (rationale) vragen● Waarom is het een requirement?● Welk businessdoel, projectdoel of

business principe dient het requirement?● Wat gaat er mis, als het requirement niet

wordt gerealiseerd?



Stap 3. Specifiëren globale requirementsGlobale requirements zijn

de resultante van het systematisch analyseren

van de informatiebehoefte

van elk bedrijfs- en werkproces (en in- en output)

naar aanleiding van een business event

BusinessEvent


Globaalrequirement



Hulpmiddel 2 – Checklist opstellen requirements (appendix C)● De checklist bevat checks met betrekking tot

● Samenhang requirement en context

● Samenhang requirement en stakeholder

● Inhoud van het requirement

● Taalgebruik in het requirement

● Samenhang requirement en proces

● Beheersaspecten van het requirement



Hulpmiddel 3 – Checklist niet-functionele requirements (appendix D)



Resultaat: globale requirements gelinkt aan high level proces


Stap 4. Bewaken traceability requirements vs oplossing

Waarom Wat Hoe

START

ITERATIE

Constraints


requirementsvs oplosssing


Stap 4. Bewaken traceability requirements - oplossing

BusinessEvent


Globaalrequirement

● Op basis van de globale requirementsbedenken business analist en vertegenwoordiger van ICTeen aantal oplossingsrichtingen (van ICT en/of procedurele oplossingen)● Focus komt nu op het HOE

● Doel: Bewaken aansluiting ● processen en requirements enerzijds ● en oplossingen anderzijds

OplossingsRichting


Stap 5. Valideren van processen en requirements met een prototype

Waarom Wat Hoe

START

ITERATIE

Constraints



Stap 5. Valideren van processen en requirements met een prototype

BusinessEvent


Globaalrequirement

● Een prototype (of proof of concept) geeft de stakeholders een beeld hoe de oplossing eruit gaat zien aan de hand van hun requirements

● De nieuwe situatie – oplossing en veranderd proces – wordt nagebootst in een processimulatie, waarbij elke stakeholder zijn rol speelt

● De stakekeholders hebben nu volop de gelegenheid te verifiëren en te valideren of bij te sturen

● Resultaat● Getoetste requirements en processen● Bijstellingen in business events en functiestroom schema's● Bijstellingen in globale requirements

PrototypeOplossings

richting


Stap 6. Prioritiseren van globale requirements

Waarom Wat Hoe

START

ITERATIE

Constraints


requirements



● Niet alle requirements kunnen in de eerstvolgende iteratie worden gerealiseerd. ● Welke zullen we kiezen?

De meest waardevolle eerst

● De opdrachtgever prioritiseert aan de hand van criteria. De lijst van criteria die hij daarbij hanteert heeft hij al in stap 1 gecommuniceerd

● Aan de hand van deze prioritisering stelt de projectmanager een iteratieplan op, waarop alle andere procesplanningsaspecten en -afspraken worden gebaseerd




Imago

1 Must Could

2 Must Must Won't Must

3 Must Must

4 Could Could Should

5 Should

6 Must Should Must

7 Could Could

8 Should Should Must Must

Nr. globaal requirement

Omzet Klant tevredenheid

Kosten reductie


Stap 7. Analyseren detail procesverandering

Waarom Wat Hoe

START

ITERATIE

Constraints

7 analyserendetail

procesverandering

7 analyserendetail

procesverandering


Stap 7. Analyseren detail procesverandering● Doel

● Bepalen van de veranderingen in de bestaande detailprocessen (activiteiten)

● Ontwerpen van to-be activiteiten

● Opstellen van business use cases

● Werking, Input en output ● Scope: de voor de gegeven iteratie geselecteerde requirements● Opdrachtgever, business analist, stakeholders en ontwikkelteam zijn actief● Zij diepen de business events en functiestroom schema's verder uit● De activiteiten van het werkproces en hun opeenvolging wordt vastgelegd

● Hulpmiddelen● Globale business events → detail business events ● Business use cases en functiestroom schema's● Checklist vragen per proces (bijlage B)



Leverancier Organisatie Klant

Kernprocessen

Supportprocessen

Governanceprocessen

Inkopen Verkopen Leveren Incasseren

Prospec-teren

Offreren Bestellen

Identificerenklant

Selecterenproduct

Bevestigen

Bedrijfsproces

Werkproces

Activiteit(nu te bepalen)

START

ITERATIES



Hulpmiddel 1 – Globale business events → detail business events

Voorbeeld

Globale business event:

Detail business events:

Klant boekt vakantie

Klant boekt vakantie: de te boeken periode ligt in het hoogseizoenKlant boekt vakantie: de te boeken periode ligt buiten het hoogseizoenKlant boekt een extra week bij een reeds bevestigde vakantieKlant wil een vakantie boeken, maar is iemand waar onze leverancier geen zaken mee doet



Hulpmiddel 2 – Business Use Case (BUC) en functiestroom schema's

Voor elk business event wordt de respons (de BUC) bepaaldDe BUC bestaat uit een aantal activiteitenGebruik de “Checklist vragen per proces” hierbij

Voorbeeld, zie hierna (niet alle input/output wordt getoond)




Klant AfdelingReserveringen

Leverancier AfdelingDebiteuren

Business EventKlant boekt

vakantie

Resultaat:Ontvangstbevestiging

Resultaat:Ontvangstbevestiging

Activiteit A

Activiteit B

Activiteit C Activiteit D

Activiteit E

Activiteit F

Resultaat:melding boeking

niet mogelijk

Resultaat:melding klant

mag niet boeken



Business Event

1

2

3

4

5

6

1

2

Klant boekt vakantie

Preconditie De te boeken periode ligt in het hoogseizoen

Activiteit

Activiteit A

Activiteit B

Activiteit C

Activiteit D

Activiteit E

Activiteit F

Resultaat Bevestiging aan klant

Bevestiging aan afd. Debiteuren

Business use case in tabelvorm


Stap 8. Specifiëren detail requirements

Waarom Wat Hoe

START

ITERATIE

Constraints


requirements


Stap 8. Specifiëren detail requirements● De globale requirements worden uitgewerkt

naar detail requirements● Stappen 7 en 8 gebeuren in dezelfde workshops.

Business use cases leiden tot detail requirements en andersom● Nu willen we in detail begrijpen wat de stakeholder wil● Let op! Nog niet over oplossingen spreken hier● Hierna worden de oplossingen uitgewerkt

● Doel ● Specificeren van de detail requirements● Koppelen van detail requirements aan activiteiten in de BUC's

● Hulpmiddelen● Checklist vragen per proces (bijlage B)● Checklist opstellen requirements (bijlage C)● Checlist niet functionele requirements (bijlage D)● Checklist rapportage requirements (bijlage E)


Stap 8. Specifiëren detail requirements● SMART maken van requirements

Specifiek, Meetbaar/testbaar, Acceptabel, Realistisch en Tijdsgebonden● Voorbeelden (meer: zie boek)

● “Reserveren moet dagelijks beschikbaar zijn”– Wordt met dagelijks bedoeld werkdagen, weekenden en feestdagen?

– Beschikbaar: 24 uur x 7 dagen?

– Geldt op elke dag dezelfde beschikbaarheid?

● “Het proces verschaft klantinformatie aan alle gebruikers”

– Welke klantinformatie wordt bedoeld?

– Met welke frequentie wordt de klantinformatie verschaft?

– Welke actualiteit moet de klantinformatie hebben?

– Wie zijn hier de gebruikers?

– Is het acceptabel dat alle gebruikers en niet speciaal daarvoor geauthoriseerden klantinformatie kunnen zien?


Stap 8. Specifiëren detail requirements

Business Event

Requirement

1a

b

2c

d

3e

f

Preconditie

Activiteit

Resultaat

Resultaat: SMART geformuleerde detail requirements● zowel functionele als niet functionele, ● gekoppeld aan activiteiten in de BUC's en ● gerelateerd aan de globale requirements


Stap 9. Bewaken traceability reqs vs opl en PDRT

Waarom Wat Hoe

START

ITERATIE

Constraints




● Doel ● Bewaken aansluiting tussen processen, requirements en oplossing● Testen van de oplossing op basis van processen en requirements● Voortschrijdend inzicht toepassen op uitwerken van de volgende iteratie

● Hulpmiddelen● Requirements Traceability Managment (RTM)




Requirements Traceability Management (RTM)


Samengevat: stappenplan

Waarom Wat Hoe

Constraints


scope /stakeholders


verandering


requirements


requirementsvs oplosssingSTART

ITERATIE



requirements

7 analyserendetail

procesverandering


requirements



Vraag & Antwoord


66

Backup Slides


Checklist C: samenhang requirement en context

1. Requirement is te herleiden tot het projectdoel

2. Requirement valt binnen de project scope

3. Requirement is te koppelen aan een business principe

4. Requirement kent een rationale die antwoord geeft op haar bestaansrecht (waarom is het een requirement?)

5. Requirement hoort bij proces, procesinput of procesoutput

6. Een detail requirement is afgeleid van een globaal requirement


Checklist C: samenhang requirement en stakeholder

7. Requirement is afkomstig van minimaal 1 stakeholderEr is 1 eigenaar per requirement

8. De stakeholder die een requirement levert, komt voor in de stakeholderanalyse en vice versa: een stakholder die voorkomt in de stakeholderanalyse heeft minimaal 1 requirement


9. Requirement geeft antwoord op de WAT-vraag.Er staan geen oplossingen of IT-begrippen in

10. Requirement is in gewone mensentaal

11. Een globaal requirement (in startup) hoeft nog niet SMART te zijn

12. Set globale requirements is dermate beschreven, dat de oplossingsalternatieven en bijhorende impact analyses voor kunnen worden gemaakt

13. Detail requirement (in een iteratie) is zo SMART mogelijk en er is voor alle stakeholders, incl eensluidend begrepen

14. Set detail requirements is dermate beschreven, dat er een definitieve oplossing met gemaakt kan worden

15. In een requirement staan geen beslissingstabellen, scenario's of document en rapportage layouts: die staan in aparte bestanden waarnaar wordt verwezen

16. Requirements kennen onderling geen conflicten

Checklist C: inhoud van een requirement


17. Tbv leesbaarheid heeft requirement uniforme zinsopbouw en één stijl van beschrijven

18. Een requirement staat zoveel mogelijk in de actieve zinHet begint met een onderwerp en een werkwoord

19. Een requirement is beschreven vanuit het betrokken proces, procesinput of -output

20. Een requirement bevat geen woorden zoals 'zullen', 'misschien', 'wellicht', 'vooral', 'in sommige gevallen'

21. Een requirement bestaat uit een bondige zin van maximum 30 woorden

22. In een requirement staan geen woorden zoals 'moeten', 'mogen', 'dienen', 'liefst'Deze begrippen staan bij het requirementattribuut 'prioriteit'

23. Er staan geen voorbeelden in een requirement

24. Er staan geen motivaties bij een requirement ('omdat', 'want')Ofwel is de motivatie een apart requirement, ofwel is het de rationale ervan

25. Een requirement bevat niet de woorden 'en' of 'of': splits in meerdere requirements

26. Er staan geen vaktermen in een requirementAls ze er wel in staan, worden ze in een verklarende woordenlijst toegelicht

Checklist C: taalgebruik in een requirement


27. Requirement is uniek identificeerbaar

28. Er is versiebeheer op de requirements

29. Een requirement kent een prioritisering (Must, Should, Could, Won't , cf. MoSCoW)

30. Requirement heeft een bron waar het is gevonden of ontstaan

31. Requirement is gereed als het gereviewed en geaccordeerd is door de stakeholder die er de eigenaar van is

32. Een requiement is getest (acceptance testing) voordat het proces of product waar het betrekking op heeft, wordt geïmplementeerd (inproductiestelling)

33. Voor ieder requirement is vast te stellen of het correct geïmplementeerd is

34. Er zijn conventies rondom naamgeving en vastlegging van globale en detail requirements, procesniveaus, stakeholders, business evevents, business use cases

Checklist C: overige kenmerken van een requirement

Date post:	18-Aug-2020
Category:	Documents
Upload:	others
View:	1 times
Download:	0 times

Process Driven Requirements Engineering PDRE · 2012. 10. 2. · Requirements Engineering PDRE ......

Documents