Profecto - REPAF

REPAFRequirement Patterns Framework

for web-based systems

Versie 1.0 - 2010André P. Wolters

Imag

e: F

ran

cesco

Marin

o / F

reeD

igita

lPh

oto

s.n

et

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

Wat is REPAF (1)? REPAF staat voor “Requirement Patterns Framework” en is de schakel

tussen de requirements definitie (probleem domein) en de oplossingen ophet 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-basedsystemen met: Meerdere stakeholders en actoren. Meerdere schermen. Meerdere (gelijktijdige) gebruikers . Complexe informatiestromen/transacties. Meerdere interfaces/web services naar (externe) systemen.

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.

Het REPAF framework (1)REPAF mindmap met (high level) gezichtspunten.

Web-based system

Project Start RequirementsDocumentatie

Migratie

Security en Privacy

Flexibiliteit

Performance

Internet Marketing Commercieel

Archivering, Backup en

PurgingLogging

Rapportages

Toegang

Interfaces

Domein Entiteiten

Schermen

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.

SchermenVoorbeelden: Functies op hoofdschermen en beheerschermen, Usability, Data standaarden.

InterfacesVoorbeelden: Throughput, Scalability, Security, Technology, Quality of Service.

Toegang systeemVoorbeelden: Registratie, Configuratie, Authenticatie, Autorisatie regels.

Het REPAF framework (3)Voorbeelden van een aantal gezichtspunten en mogelijke patterns:

Rapportages en documentatieVoorbeelden: SLA rapportages, Financiële rapportage, Handleidingen, Trainingen, Business Process Modelling.

Archivering en LoggingVoorbeelden: Data beschikbaarheid, Bewaartermijn, Audit trails, Error logs, Functionele logs.

Performance en Flexibiliteit Voorbeelden: Response Time, Throughput, Schaalbaarheid, Beschikbaarheid, Beheerbaarheid, Testbaarheid.

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.

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.

REPAF in de praktijk (3)Probleem domein en de relatie met het oplossingsdomein.

Probleem domein

Oplossingen

Geef relaties aan tussen requirements. Bepaal eerst wat de echte top-eisen zijn van het

systeem. Werk top-down naar sub-eisen net zo ver tot eventuele “risico’s” aanvaardbaar zijn.

Geef relaties aan tussen requirements en oplossing(en). Welke requirement wordt door welke oplossing gerealiseerd (Traceability).

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.

REPAF in de praktijk (4)Sturen op resultaat. Top-down naar oplossing en taken (Synergio methodiek).

Requirements

Requirements Breakdown Structure

Oplossing

Product Breakdown Structure

Management van Requirement,

Product en Work Breakdown Structures

Taken

Work Breakdown Structure

Opdrachtgever en opdrachtnemer onderhandelen over maakbaarheid en haalbaarheid van de requirements.

Maakbaarheid Haalbaarheid

Het resultaat

REPAF in de praktijk (5)Algemene praktische zaken:

Gebruik REPAF als een handvat om een goede start te kunnen maken ineen 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.

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.”

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.

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

Informatie REPAFAndré P. [email protected]