Process Driven Requirements Engineering PDRE · 2012. 10. 2. · Requirements Engineering PDRE ......
Transcript of Process Driven Requirements Engineering PDRE · 2012. 10. 2. · Requirements Engineering PDRE ......
1
Toegepaste Informatica
Bachelorproef
Process Driven Requirements Engineering
PDRE ®
PDRE is een gedeponeerd merk van Qquest - 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
Bron: http://www.qquest.nl/ en "Process Driven Requirements Engineering", R. Harreman, Qquest 2011 5
Waarom – Wat – Hoe Model
Waarom● Welk probleem wil men oplossen?
● Wat zijn de doelstellingen van het project?
● Wat is de scope van het project?
● Wie zijn de stakeholders?
Bron: http://www.qquest.nl/ en "Process Driven Requirements Engineering", R. Harreman, Qquest 2011 6
Waarom – Wat – Hoe Model
Wat
Gegeven het waarom
● Wat zijn de (veranderingen aan de) processen?
● Wat zijn de requirements die daarbij horen?
Bron: http://www.qquest.nl/ en "Process Driven Requirements Engineering", R. Harreman, Qquest 2011 7
Waarom – Wat – Hoe Model
HoeHet hoe omvat:
● ICT-oplossingen
● handmatige procedures
● afspraken met ketenpartners,
● bezettingen op afdelingen
● enzovoort
Bron: http://www.qquest.nl/ en "Process Driven Requirements Engineering", R. Harreman, Qquest 2011 8
Waarom – Wat – Hoe Model
Waarom Wat Hoe
OplossingenProcessen enrequirements
ProbleemDoelstellingenStakeholders
Ook: oplossingen zijn er voor requirements,die voortvloeien uit de probleemstelling
Bron: http://www.qquest.nl/ en "Process Driven Requirements Engineering", R. Harreman, Qquest 2011 9
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
Bron: http://www.qquest.nl/ en "Process Driven Requirements Engineering", R. Harreman, Qquest 2011 10
Eisen aan requirements engineering
Bron: http://www.qquest.nl/ en "Process Driven Requirements Engineering", R. Harreman, Qquest 2011 11
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
Bron: http://www.qquest.nl/ en "Process Driven Requirements Engineering", R. Harreman, Qquest 2011 12
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
Bron: http://www.qquest.nl/ en "Process Driven Requirements Engineering", R. Harreman, Qquest 2011 13
Requirements moeten uiteindelijk SMART zijn
Specifiek,
Meetbaar/testbaar,
Acceptabel,
Realistisch en
Tijdsgebonden
RF foto's Dreamstime
Bron: http://www.qquest.nl/ en "Process Driven Requirements Engineering", R. Harreman, Qquest 2011 14
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
Bron: http://www.qquest.nl/ en "Process Driven Requirements Engineering", R. Harreman, Qquest 2011 17
Globale vs Detail requirements
Bron: http://www.qquest.nl/ en "Process Driven Requirements Engineering", R. Harreman, Qquest 2011 18
Voorbeelden van 4 soorten requirements
Bron: http://www.qquest.nl/ en "Process Driven Requirements Engineering", R. Harreman, Qquest 2011 19
Constraints
Constraints vormen kaders en randvoorwaarden waarbinnen requirements van toepassing zijn.
Constraints zijn niet onderhandelbaar
Functionele requirements
Niet functionele requirements
Businessconstraints
Projectconstraints
Technischeconstraints
Oplossingsconstraints
Bron: http://www.qquest.nl/ en "Process Driven Requirements Engineering", R. Harreman, Qquest 2011 20
PDRE Framework
Bron: Project-management volgens Prince2 – Peter Janssen
Prince2 procesmodel
START
ITERATIES
Copyright © 2009 - Green10 22
De ontwikkelingscyclus onder Scrum
Bron: http://www.mountaingoatsoftware.com
STARTITERATIES
Bron: http://www.qquest.nl/ en "Process Driven Requirements Engineering", R. Harreman, Qquest 2011 23
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)
Bron: http://www.qquest.nl/ en "Process Driven Requirements Engineering", R. Harreman, Qquest 2011 24
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
Bron: http://www.qquest.nl/ en "Process Driven Requirements Engineering", R. Harreman, Qquest 2011 25
Stap 1. Definiëren projectdoel, scope en stakeholders
Waarom Wat Hoe
START
ITERATIE
Constraints
1. definiëren doel /
scope /stakeholders
Bron: http://www.qquest.nl/ en "Process Driven Requirements Engineering", R. Harreman, Qquest 2011 26
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
RF foto's Dreamstime
Bron: http://www.qquest.nl/ en "Process Driven Requirements Engineering", R. Harreman, Qquest 2011 28
Stap 2. Analyseren globale procesverandering
Waarom Wat Hoe
START
ITERATIE
Constraints
2. analyserenglobaleproces
verandering
Bron: http://www.qquest.nl/ en "Process Driven Requirements Engineering", R. Harreman, Qquest 2011 29
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
Bron: http://www.qquest.nl/ en "Process Driven Requirements Engineering", R. Harreman, Qquest 2011 30
Stap 2. Analyseren globale procesverandering
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
Bron: http://www.qquest.nl/ en "Process Driven Requirements Engineering", R. Harreman, Qquest 2011 31
Stap 2. Analyseren globale procesverandering
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
Bron: http://www.qquest.nl/ en "Process Driven Requirements Engineering", R. Harreman, Qquest 2011 32
Stap 2. Analyseren globale procesverandering
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
Bron: http://www.qquest.nl/ en "Process Driven Requirements Engineering", R. Harreman, Qquest 2011 33
Stap 2. Analyseren globale procesverandering
Hulpmiddel 2 – Business events en functiestroom schema's
Klant AfdelingReserveringen
Leverancier AfdelingDebiteuren
Business EventKlant boekt
vakantie
Input
Boeken
Output
Input
Goedkeuren
Output
BevestigenResultaatOntvangstbevestiging
ResultaatOntvangstbevestiging
Bron: http://www.qquest.nl/ en "Process Driven Requirements Engineering", R. Harreman, Qquest 2011 34
Stap 2. Analyseren globale procesverandering
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?
Bron: http://www.qquest.nl/ en "Process Driven Requirements Engineering", R. Harreman, Qquest 2011 35
Stap 2. Analyseren globale procesverandering
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
Bron: http://www.qquest.nl/ en "Process Driven Requirements Engineering", R. Harreman, Qquest 2011 36
Stap 3. Specifiëren globale requirements
Waarom Wat Hoe
START
ITERATIE
Constraints
3. specifiërenglobale
requirements
Stappen 2 en 3 gebeuren in de praktijk gelijktijdig en iteratief
Bron: http://www.qquest.nl/ en "Process Driven Requirements Engineering", R. Harreman, Qquest 2011 37
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)
Bron: http://www.qquest.nl/ en "Process Driven Requirements Engineering", R. Harreman, Qquest 2011 38
Stap 3. Specifiëren globale requirements
● 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?
RF foto's Dreamstime
Bron: http://www.qquest.nl/ en "Process Driven Requirements Engineering", R. Harreman, Qquest 2011 39
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
Procesmet inputen output
Globaalrequirement
Bron: http://www.qquest.nl/ en "Process Driven Requirements Engineering", R. Harreman, Qquest 2011 40
Stap 3. Specifiëren globale requirements
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
Bron: http://www.smartest.nl/verdieping/kwaliteitsmodellen/iso9126 41
Stap 3. Specifiëren globale requirements
Hulpmiddel 3 – Checklist niet-functionele requirements (appendix D)
Bron: http://www.qquest.nl/ en "Process Driven Requirements Engineering", R. Harreman, Qquest 2011 42
Stap 3. Specifiëren globale requirements
Resultaat: globale requirements gelinkt aan high level proces
Bron: http://www.qquest.nl/ en "Process Driven Requirements Engineering", R. Harreman, Qquest 2011 43
Stap 4. Bewaken traceability requirements vs oplossing
Waarom Wat Hoe
START
ITERATIE
Constraints
4. bewakentraceability
requirementsvs oplosssing
Bron: http://www.qquest.nl/ en "Process Driven Requirements Engineering", R. Harreman, Qquest 2011 44
Stap 4. Bewaken traceability requirements - oplossing
BusinessEvent
Procesmet inputen output
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
Bron: http://www.qquest.nl/ en "Process Driven Requirements Engineering", R. Harreman, Qquest 2011 45
Stap 5. Valideren van processen en requirements met een prototype
Waarom Wat Hoe
START
ITERATIE
Constraints
5. validerenprocessen enrequirements obv prototype
Bron: http://www.qquest.nl/ en "Process Driven Requirements Engineering", R. Harreman, Qquest 2011 46
Stap 5. Valideren van processen en requirements met een prototype
BusinessEvent
Procesmet inputen output
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
Bron: http://www.qquest.nl/ en "Process Driven Requirements Engineering", R. Harreman, Qquest 2011 47
Stap 6. Prioritiseren van globale requirements
Waarom Wat Hoe
START
ITERATIE
Constraints
6. prioriterenglobale
requirements
Bron: http://www.qquest.nl/ en "Process Driven Requirements Engineering", R. Harreman, Qquest 2011 48
Stap 6. Prioritiseren van globale 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
RF foto's Dreamstime
Bron: http://www.qquest.nl/ en "Process Driven Requirements Engineering", R. Harreman, Qquest 2011 49
Stap 6. Prioritiseren van globale requirements
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
Bron: http://www.qquest.nl/ en "Process Driven Requirements Engineering", R. Harreman, Qquest 2011 50
Stap 7. Analyseren detail procesverandering
Waarom Wat Hoe
START
ITERATIE
Constraints
7 analyserendetail
procesverandering
7 analyserendetail
procesverandering
Bron: http://www.qquest.nl/ en "Process Driven Requirements Engineering", R. Harreman, Qquest 2011 51
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)
Bron: http://www.qquest.nl/ en "Process Driven Requirements Engineering", R. Harreman, Qquest 2011 52
Stap 7. Analyseren detail procesverandering
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
Bron: http://www.smartest.nl/verdieping/kwaliteitsmodellen/iso9126 53
Stap 7. Analyseren detail procesverandering
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
Bron: http://www.smartest.nl/verdieping/kwaliteitsmodellen/iso9126 54
Stap 7. Analyseren detail procesverandering
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)
Bron: http://www.qquest.nl/ en "Process Driven Requirements Engineering", R. Harreman, Qquest 2011 55
Stap 7. Analyseren detail procesverandering
Hulpmiddel 2 – Business events en functiestroom schema's
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
Bron: http://www.qquest.nl/ en "Process Driven Requirements Engineering", R. Harreman, Qquest 2011 56
Stap 7. Analyseren detail procesverandering
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
Bron: http://www.qquest.nl/ en "Process Driven Requirements Engineering", R. Harreman, Qquest 2011 57
Stap 8. Specifiëren detail requirements
Waarom Wat Hoe
START
ITERATIE
Constraints
8. specifiërendetail
requirements
Bron: http://www.qquest.nl/ en "Process Driven Requirements Engineering", R. Harreman, Qquest 2011 58
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)
Bron: http://www.qquest.nl/ en "Process Driven Requirements Engineering", R. Harreman, Qquest 2011 59
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?
Bron: http://www.qquest.nl/ en "Process Driven Requirements Engineering", R. Harreman, Qquest 2011 60
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
Bron: http://www.qquest.nl/ en "Process Driven Requirements Engineering", R. Harreman, Qquest 2011 61
Stap 9. Bewaken traceability reqs vs opl en PDRT
Waarom Wat Hoe
START
ITERATIE
Constraints
9. bewakentraceabilityreqs vs oplen PDRT
Bron: http://www.qquest.nl/ en "Process Driven Requirements Engineering", R. Harreman, Qquest 2011 62
Stap 9. Bewaken traceability reqs vs opl en PDRT
● 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)
RF foto's Dreamstime
Bron: http://www.qquest.nl/ en "Process Driven Requirements Engineering", R. Harreman, Qquest 2011 63
Stap 9. Bewaken traceability reqs vs opl en PDRT
Requirements Traceability Management (RTM)
Bron: http://www.qquest.nl/ en "Process Driven Requirements Engineering", R. Harreman, Qquest 2011 64
Samengevat: 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
Copyright © 2012 - Green10 65
Vraag & Antwoord
RF foto's Dreamstime
66
Backup Slides
Bron: http://www.qquest.nl/ en "Process Driven Requirements Engineering", R. Harreman, Qquest 2011 67
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
Bron: http://www.qquest.nl/ en "Process Driven Requirements Engineering", R. Harreman, Qquest 2011 68
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
Bron: http://www.qquest.nl/ en "Process Driven Requirements Engineering", R. Harreman, Qquest 2011 69
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
Bron: http://www.qquest.nl/ en "Process Driven Requirements Engineering", R. Harreman, Qquest 2011 70
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
Bron: http://www.qquest.nl/ en "Process Driven Requirements Engineering", R. Harreman, Qquest 2011 71
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