Veel organisaties vinden requirement development-activiteiten een van de moeilijkere aspecten van requirements engineering. Zij hebben problemen met het verzamelen, analyseren, documenteren en valideren van requirements. Dit blijkt uit het RE Compass 2012-rapport van ict-dienstverlener Devoteam in samenwerking met ict-leverancier IBM Nederland.
Het RE Compass is een nieuw initiatief gestart door Devoteam in samenwerking met IBM Nederland. Na de positieve ontvangst van de eerste RE Compass in 2010 besloot Devoteam het onderzoek te herhalen. Deze keer ligt de focus van het onderzoek op requirement-ontwikkeling. In het vorige onderzoek is duidelijk naar voren gekomen dat requirement-ontwikkeling één van de moeilijkste aspecten is van requirement engineering. Het thema voor dit jaar is hier van afgeleid. Het rapport laat zien waar de problemen liggen bij het vergaren, analyseren, documenteren en valideren van requirements.
Projectsucces
Requirement-activiteiten vinden vaak plaats in het kader van projecten. Daarom stelt het onderzoek een aantal vragen over de projecten waarin requirements worden verzameld. Hieruit blijkt dat een tevreden klant belangrijker voor een project is dan de te behalen financiële voordelen. Klanttevredenheidsmeting wordt drie keer vaker toegepast dan tastbare kostenbesparingen of inkomstenverhoging. Opvallend is dat bijna 15 procent van de organisaties niet mee doet aan het meten van het projectsucces.
Uit het onderzoek blijkt ook dat het gebrek aan volledigheid en duidelijkheid in requirements het grootste probleem is tijdens de requirement-ontwikkeling. Dat is volgens onderzoeker Katarzyna Kot van Devoteam niet verwonderlijk, aangezien de requirements vooral gedocumenteerd worden als platte tekst en verspreid worden in de vorm van documenten of spreadsheets. 'Een derde van de respondenten weet niet hoeveel requirements de projecten in hun organisatie hebben. Het gebrek aan volledigheid in de requirements-documenten heeft een relatie met de requirements-elicitatiefase. Businessanalisten hebben de neiging om elicitatietechnieken van hun eigen voorkeur te gebruiken, die niet noodzakelijkerwijs passen bij de bedrijfssituatie. Dit kan uiteindelijk leiden tot ontbrekende requirements.'
Verbeteringen
In het onderzoek is ook gekeken naar requirement-validatie en dan blijkt dat 61 procent van de respondenten de executie van een projectstart in gaat zonder goedgekeurde requirements indien het risico ervan beheersbaar is. Om dit risico te verminderen, maken projecten gebruik van interactieve validatietechnieken om fouten vroegtijdig te erkennen en repareren. In het algemeen zijn de Nederlandse organisaties positief over hoe zij de requirements-ontwikkeling uitvoeren. Toch toont het onderzoek een aantal verbetermogelijkheden, dat kan leiden tot betere en efficiëntere requirement-procesuitvoering. De meest genoemde verbeteringen zijn de bewustwording over het belang van requirements-proces onder business vertegenwoordigers en een structurele aanpak tot requirement development.
Verbazingwekkend om te lezen dat requirements anno 2012 nog steeds gedocumenteerd worden in platte tekst. Veel organisaties hebben inmiddels al geleerd dat directe communicatie, bv. met Scrum tussen een Product Owner en een Team veel effectiever is. Het hoe en waarom van requirements is veel beter over te brengen en af te stemmen, waardoor een team de juiste oplossing kan ontwikkelen. Om die vervolgens in een sprint review / demo te laten zien aan de klanten en stakeholders. Waar wachten al die organisaties die nog worstelen met onvolledige en onduidelijke requirements op?
De kern van het probleem is niet de vorm waarin requirements worden vastgelegd! En ook niet de methode die wordt gevolgd. Waar het om gaat is dat het duidelijk is wat je met zijn allen nou eigenlijk gaat maken en dat iedereen daarbij op de zelfde pagina zit. Oftewel weten we met zijn allen wat we moeten doen, zijn we het daar allemaal over eens, en hebben we ook goede afspraken gemaakt hoe we toetsen of het resultaat is zoals we hadden afgesproken ook is behaald?
En inderdaad, veel mensen en bedrijven worstelen hiermee, ongeacht of ze platte tekst gebruiken, of scrummen (ja, helaas ook daar nog steeds), of wat voor aanpak ook. Het is toch een vak! Maar het goede nieuws is dat iedereen deze vaardigheden gewoon kan leren!
Requirements worden vaak verward met solutions. Ipv de vraag om capaciteit worden er vaak volledige specs meegegeven. Dit komt vaak omdat men niet altijd zijn rol in de organisatie goed begrijpt, of te vaak teruggrijpt op de kennis die men heeft.
Het definiëren van eisen en wensen, dus vergt kennis en kunde.
Het beschrijven van een volgende communicatie-infrastructuur vergt dus inzicht, doorzicht en kennis. Veelal is die niet beschikbaar in de bestaande organisatiestructuur, omdat de huidige infrastructuur 6 tot 8 jaar oud is en er een veelheid aan nieuwe mogelijkheden is gekomen in die tussen tijd, en omdat een staande organisatie druk is met het huidige werk en daardoor weinig tijd of zicht heeft op : “what’s THE next generation”
Zou het niet zo kunnen zijn dat, naarmate de organisatie groter (en daarmee vaak ook complexer) wordt, de rol van product owner minder waard wordt?
– naarmate de organisatie meer “lagen” kent, neemt de afstand tussen product owner en de echte eindgebruiker ook toe.
– naarmate een organisatie groter wordt, ontstaan er binnen één groep van stakeholders verscheidene meningen. Betreffende stakeholder spreekt niet meer “met één stem” waardoor de product owner ook niet meer weet wat die stakeholder nu wel of niet wil
– binnen een grotere organisatie zijn ook meer conflicten tussen diverse stakeholders, waar de product owner uiteindelijk de dupe van is; hij wordt immers op en neer geslingerd tussen de diverse partijen
En zoals Ruud terecht opmerkt, veel requirements worden als halve specs aangeleverd. Het lastigste van requirement development is het definiëren van het detailniveau. Je wil niet ieder scherm of functionaliteit uit hoeven schrijven, maar als het te abstract is krijg je weer niet wat je hebben wil.
In mijn ogen heb je dit probleem vooral wanneer je code door een derde partij laat maken. Binnen een R&D afdeling hebben mensen domeinkennis, waardoor de mensen requirements veel beter kunnen interpreteren dan bij uitbesteding.