•  
•  
•  
•  

0 Reacties Bewaren

Stel je goede requirements op voor softwareontwikkeling, dan volgt de rest vanzelf. Dat betoogt Forrester-analist Tom Grant.

Revoluties kunnen verschillende gedaanten aannemen. De meest tot de verbeelding sprekende variant is het opvallend heftige, disjunctieve gebeuren waarbij een snelle, volledig breuk met het verleden wordt voltooid. Gisteren was Mubarak nog president, vandaag is hij het niet meer. Andere soorten revoluties verlopen subtieler en meer geleidelijk en zorgen vanzelf voor een nieuwe realiteit.

De schok na Pearl Harbour, het machtsvacuüm in Europa en Japan, een uitgeholde economie en een agressieve supermacht zorgden er bij de Amerikanen voor dat het isolationistische beleid van de VS op de schop moest. Zonder dat dit ergens formeel werd vastgelegd, gingen de VS een internationalistische koers varen na 1945.

Softwaretragedies

Zulke revoluties vinden ook plaats bij software requirements. Het afgelopen decennium zijn organisaties zich vaker zorgen gaan maken over problemen waarbij de oorzaak te herleiden is naar slechte requirements. De problemen namen verschillende vormen aan (portfolio's raakten vervuild met software die niemand gebruikte, gebruikers werden ongelukkig van software die zaken onnodig gecompiliceerd maakten, ideeën werden nooit goed onderzocht, etc.) en onstonden vanuit vele verschillende bronnen.

Al deze onhebbelijkheden wezen in dezelfde richting: Neem requirements serieuzer. In recent onderzoek van Forrester (Application Development and Delivery Organisation Structure Online Survey Q1) verschijnt requirements op plaats één als het gaat om initiatieven die het meest zouden helpen bij het verbeteren van softwareontwikkeling.

De stille revolutie in requirements is het onderwerp van een recent onderzoeksdocument van ondergetekende. Veel problemen hebben geleid tot vele nieuwe handelswijzen en disciplines, zoals visualisatie, en verdreven oudere methoden als modelgebaseerde requirements.

Oplossingen liggen voor het oprapen

Op dit moment hebben leveranciers, die een gat in de markt roken, allerlei fantastische nieuwe tools uitgebracht. Sommige zijn enorm gespecialiseerd voor bepaalde taken, zoals Balsamiq en iRise voor visualisatie. Andere tools combineren vele mogelijkheden op dezelfde manier als een Zwitsers zakmes dat doet, zoals Blueprint en eDev. En dan zijn er nog een hoop nieuwe op requirements gerichte bedrijven waarvan de meeste tien jaar geleden nog niet begonnen.

Door de gehele ontwikkelingscyclus voor software is er maar één plek waar je de definitie van de waarde van de software kunt vinden (of zou moeten kunnen vinden), namelijk in de requirements. Het document bespreekt in detail de gebruiksscenario's, persona's, niet-functionele requirements, roadmaps, prioriteiten en andere facetten die maken dat de software waardevol wordt voor de eindgebruiker en waarom er een goede reden is voor de bouwer om het te ontwikkelen.

Wanneer requirements niet in staat zijn om deze waarde te definieren, lopen softwareontwikkeling en het in gebruik nemen ervan grotere risico's. We voegen nieuwe software gauw aan ons portfolio toe en krijgen daar later spijt van. We bouwen software die goed werkt, maar niet voor de mensen die ermee moeten werken. We slagen er niet in te communiceren wat realistisch gebruik van de software is volgens de mensen die het testen. We lanceren veel te traag nieuwe mogelijkheden die de problemen van eindgebruikers oplossen of juist te snel zodat er niet geacclimatiseerd kan worden.

Integrale aanpak

In de gehele keten zou een gedeelde visie moeten ontstaan over hetgeen gebouwd wordt, voor wie het gebouwd wordt en wat welk voordeel het inhoudt voor zowel de producent als de klant. Zonder zoiets worden slimme mensen met goede intenties en geweldige skills ingezet om de verkeerde testdocumentatie te schrijven, de verkeerde gebruikservaring te ontwerpen of de verkeerde prioriteiten te stellen.

Dit is de verandering in denken die plaats moet vinden over requirements. De vereisten aan software moeten bovenaan de prioriteitenlijst staan. Daarnaast moeten mensen ervoor verantwoordelijk gesteld worden. Zij zouden niet bang moeten zijn om te investeren in nieuwe handelswijzen (practices) en tools.

Tom Grant is senior analist bij Forrester en gespecialiseerd in applicatieontwikkeling. Zijn onderzoeksgebieden zijn onder meer innovatie, Agile, productmanagement, social media als input voor ontwikkeling, application lifecycle management en embedded software.

Lees meer over

• software
• onderzoek
• Forrester
• developers
• eisen
• Development
• tools
• ontwikkeling
• requirements