REPAF. Requirement Patterns Framework for web-based systems.

1. Image: Francesco Marino / FreeDigitalPhotos.net
REPAF
Requirement Patterns Framework
for web-based systems
André P. Wolters Versie 1.0 - 2010

2. Hergebruik van requirements…
 In de requirement specificaties van complexe web-based systemen zijn
patronen (patterns) te herkennen die vaak terugkomen.
 Waarom deze patronen niet in kaart brengen en hergebruiken?
…..in plaats van steeds opnieuw het wiel uitvinden.
REPAF

3. Wat is REPAF (1)?
 REPAF staat voor “Requirement Patterns Framework” en is de schakel
tussen de requirements definitie (probleem domein) en de oplossingen op
het snijvlak van Business en ICT.
 REPAF richt zich op requirement patterns die vaak aanwezig zijn in het
probleem domein van web-based systemen.
NB. REPAF focust niet op design-patterns (oplossingen) maar op patterns die requirements van
stakeholders aangeven.
NB2. In deze presentatie wordt met requirements, de behoefte/eisen van de stakeholders
bedoeld.
 REPAF is een framework waarbij de focus ligt op (complexe) web-based
systemen met:
 Meerdere stakeholders en actoren.
 Meerdere schermen.
 Meerdere (gelijktijdige) gebruikers .
 Complexe informatiestromen/transacties.
 Meerdere interfaces/web services naar (externe) systemen.

4. Wat is REPAF (2)?
 Binnen het framework zijn meerdere aandachtsgebieden gedefinieerd.
Dit worden ook wel gezichtspunten genoemd.
 Vanuit elk gezichtspunt zijn veel voorkomende patterns gedefinieerd.
 Het framework biedt daarnaast ook structuur om te komen tot:
 Een completere en juiste verzameling requirements.
 Een eenduidige definitie van de requirements.
 Koppeling van requirements naar oplossingen.
 Sturen op basis van requirements.

5. Het REPAF framework (1)
REPAF mindmap met (high level) gezichtspunten.
Project Start
Documentatie Requirements Schermen
Domein
Migratie
Entiteiten
Security en Interfaces
Privacy
Web-based
system
Flexibiliteit Toegang
Performance Rapportages
Internet Archivering,
Marketing Commercieel Backup en Logging
Purging

6. Het REPAF framework (2)
Voorbeelden van een aantal gezichtspunten en mogelijke patterns:
 Project Start Requirements
Deze patterns hebben o.a. betrekking op de beperking/beheersing van het beoogde
systeem.
Voorbeelden: Business Value, Voldoen aan project start architecturen, Voldoen aan project
standaarden, Bedrijfsstandaarden, Wettelijke regels, Beperkingen m.b.t. technologie,
Stakeholder management, Haalbaarheidseisen.
 Schermen
Voorbeelden: Functies op hoofdschermen en beheerschermen, Usability, Data standaarden.
 Interfaces
Voorbeelden: Throughput, Scalability, Security, Technology, Quality of Service.
 Toegang systeem
Voorbeelden: Registratie, Configuratie, Authenticatie, Autorisatie regels.

7. Het REPAF framework (3)
Voorbeelden van een aantal gezichtspunten en mogelijke patterns:
 Rapportages en documentatie
Voorbeelden: SLA rapportages, Financiële rapportage, Handleidingen, Trainingen, Business
Process Modelling.
 Archivering en Logging
Voorbeelden: Data beschikbaarheid, Bewaartermijn, Audit trails, Error logs, Functionele logs.
 Performance en Flexibiliteit
Voorbeelden: Response Time, Throughput, Schaalbaarheid, Beschikbaarheid,
Beheerbaarheid, Testbaarheid.

8. REPAF in de praktijk (1)
Bepaal de “ruimte” waarbinnen de requirements zich bevinden.
Met name het gezichtspunt “Project Start Requirements” zal worden toegepast.
In deze stap is het belangrijk om de grenzen (beperking/beheersing) van het “beoogde”
systeem zo snel en goed mogelijk te bepalen om later scope creeping te voorkomen.
Binnen deze grenzen bevinden zich de
requirements van de stakeholders.
De requirements zijn hier nog “blanco”
en worden in een volgende stap bepaald.

9. REPAF in de praktijk (2)
Bepaal via de diverse gezichtspunten de requirements van het beoogde
systeem.
NB. Het framework is een handvat waarbij andere gezichtspunten ook gebruikt en toegepast
kunnen worden voor het vinden van requirements.
Doel: Vul de “ruimte” waarin de requirements zich bevinden zo goed mogelijk door vanuit
diverse gezichtspunten naar het beoogde systeem te kijken met verschillende stakeholders.
Waarom?: Krijg een completere en juiste verzameling requirements door
vanuit verschillende gezichtspunten te kijken. Reduceer hiermee risico’s en
krijg oplossingen die ook (beter) voldoen aan de behoefte van de stakeholders.

10. REPAF in de praktijk (3)
Probleem domein en de relatie met het oplossingsdomein.
Geef relaties aan
tussen requirements. Bepaal eerst wat de echte top-eisen zijn van het
systeem. Werk top-down naar sub-eisen net zo
Probleem domein ver tot eventuele “risico’s” aanvaardbaar zijn.
Geef relaties aan tussen requirements en
oplossing(en). Welke requirement wordt door
welke oplossing gerealiseerd (Traceability).
Oplossingen
De kunst is om een balans te vinden tussen hoe
ver te gaan in het verzamelen van requirements
en de vrijheid (oplossingsruimte) die aan de
leverancier/opdrachtnemer wordt gegeven.

11. REPAF in de praktijk (4)
Sturen op resultaat. Top-down naar oplossing en taken (Synergio methodiek).
Het resultaat
Opdrachtgever en opdrachtnemer
onderhandelen over maakbaarheid en
haalbaarheid van de requirements.
Requirements
Requirements
Breakdown
Structure
Maakbaarheid Haalbaarheid
Management van
Requirement,
Product en Work
Breakdown
Structures
Oplossing Taken
Product
Work Breakdown
Breakdown
Structure
Structure

12. REPAF in de praktijk (5)
Algemene praktische zaken:
 Gebruik REPAF als een handvat om een goede start te kunnen maken in
een project.
 Schrijf SMART requirements.
Opdrachtgever en opdrachtnemer moeten een eenduidig beeld hebben van de
requirements en daarmee de behoefte.
 Gebruik een tool om de requirements vast te leggen en te managen.
NB. Het vastleggen en managen van requirements met een WORD doc of een Excel sheet
verhoogt het risico dat er relatief te veel tijd wordt besteed aan het beheer van deze
documenten en te weinig tijd aan het vinden van een goede verzameling requirements.
Het gevolg: Een grotere kans dat de uiteindelijke oplossingen niet voldoen aan de behoefte.

13. Waarom REPAF (1)?
“Om oplossingen te krijgen die (beter) voldoen aan de
behoefte van de stakeholders, waarbij de oplossing een
toegevoegde waarde heeft (business value) en een
investering die gerechtvaardigd is.”

14. Waarom REPAF (2)?
Kenmerken van REPAF die dit mogelijk maken:
 Structuur in het vinden van de juiste requirements.
Het framework met diverse gezichtspunten en requirement patterns biedt structuur in het
proces van het vinden van een goede verzameling requirements.
 Het vinden van een completere en juiste verzameling van requirements.
Het framework dekt de “ruimte” waarin de requirements zich bevinden beter af. Door met
verschillende stakeholders te kijken via deze gezichtspunten, wordt de kwaliteit, juistheid en
volledigheid, van de verzameling requirements hoger en zorgt daarmee voor oplossingen die
(beter) voldoen aan de behoefte van de stakeholders.
 Het sneller vinden van “risicovolle” requirements.
Door te kijken via verschillende gezichtspunten worden requirements met een hogere risico
eerder onderkend.
 Sturen en focus op resultaat.
Onderhandel over maakbaarheid en haalbaarheid met als uitgangspunt dat de op te leveren
oplossing toegevoegde waarde heeft voor de klant en de investering hierin gerechtvaardigd is.

15. Geraadpleegde bronnen REPAF
 Best practices en lessons learned.
Sinds eind 1999 gewerkt op diverse (grote) web-based projecten voor:
KPN, Friesland Bank en Achmea.
Als: Software Engineer, Technisch Ontwerper, Functioneel Ontwerper,
Requirements Engineer, Informatie Analist.
 Synergio methodiek (Trainingen gevolgd bij Synergio).
 Literatuur van bekende guru’s op het gebied van requirements:
 Suzanne Robertson en James Robertson
 Karl Wiegers
 Stephen Withall
 Tom Gilb
 Diverse andere literatuur, artikelen en papers op het gebied van:
 Requirements
 Stakeholder management
 Ontwerp: Use Cases (o.a. Cockburn), UML
 Agile development: RUP, SCRUM

16. Informatie REPAF
André P. Wolters
info@profecto.nl
www.profecto.nl