James Robertson geeft driedaagse workshop over Requirements

Deel dit bericht

Requirements bepalenwat de IT-klant wilJames Robertson, mede-auteur van het standaardwerk ‘Mastering the Requirements Process’, is van 2 tot en met 4 maart 2010 in Nederland voor een workshop over requirements management. Daarbij gaat hij uitgebreid in op een van de lastigste onderdelen van een succesvol softwareproject: hoe bepaal je wat de business nodig heeft. Vaak kan de business dat zelf niet duidelijk omschrijven, maar er zijn goede technieken die dat wel voor elkaar krijgen.

James Robertson geeft driedaagse workshop over RequirementsRequirements bepalenwat de IT-klant wilJames Robertson, mede-auteur van het standaardwerk ‘Mastering the Requirements Process’, is van 2 tot en met 4 maart 2010 in Nederland voor een workshop over requirements management. Daarbij gaat hij uitgebreid in op een van de lastigste onderdelen van een succesvol softwareproject: hoe bepaal je wat de business nodig heeft. Vaak kan de business dat zelf niet duidelijk omschrijven, maar er zijn goede technieken die dat wel voor elkaar krijgen.UML, RUP, Scrum, XP en nog zo’n veertig andere technieken geven allemaal wel wat informatie om de requirements voor een software-project te achterhalen. Als de systeemontwerper handig genoeg is en over voldoende sociale eigenschappen beschikt, kan hij daar aardig mee uit de voeten. Maar echt uitputtend is de informatie niet. Het echtpaar Suzanne en James Robertson heeft er een levenswerk van gemaakt om hier verbetering in aan te brengen. Om het gat tussen IT en business te dichten. Ruim twintig jaar ervaring en nauwkeurige bestudering van de verschillende technieken leidden tot ‘Mastering the Requirements’: het standaardwerk voor iedere systeemontwerper of softwarearchitect.Robertson: “Te vaak beginnen architecten of ontwikkelaars aan een project met een voorstelling van hoe het uiteindelijke softwareproduct eruit ziet, zonder ooit te kijken naar wat nu eigenlijk het probleem van de business is. Je mag natuurlijk best ideeën hebben over het softwareproduct, maar je moet ook kunnen aangeven wat dit zal betekenen voor de business. Welk effect dit zal hebben op het werk en het resultaat van de business. Leiden mijn veronderstellingen daadwerkelijk tot de oplossing, die de klant van me vraagt? Waar het bij de requirements om gaat is begrip van het werk van de business, zodat je een product kunt leveren, waardoor het beter gaat werken.En het maakt niet uit over welke business het gaat. Of het nu gaat over de chemiesector, de bankwereld, een bibliotheek of een producent van tv’s, dat maakt niet uit. Het gaat om ‘Het Werk’”.Robertson geeft toe dat het moeilijk is aan te geven wat het belangrijkste deel van het proces is. Erg belangrijk is dat je de data definieert. Zonder dat blijft er te veel ruimte voor interpretatie. Er bestaat heel veel kennis over het definiëren en modelleren van data. Je hoeft geen datamodellen aan de business te laten zien. Maar als je een scope gaat vaststellen en data gaat in- en uitvoeren rond de business rules, kijken al die business rules naar de data. Beslissingen nemen of berekeningen maken gebeurt op basis van waarden van die data. Dat is simplistisch, maar het is wel de essentie van een business systeem.“Als je de data vroeg in het project kunt identificeren en kunt groeperen heb je de basis om naar ieder stukje van die data te kijken en je af te vragen: kunnen we daar requirements uit afleiden? Moeten we iets updaten of verwijderen. Welke waarde kunnen we aan die data ontlenen. Een goede omschrijving van de data leiden de software-architect door het hele proces heen”.De workshop Mastering the Requirements Process wordt van 2 t/m 4 maart gehouden in Hotel Lapershoek te Hilversum. Meer informatie op www.arrayseminars.nl