Archive for category Requirements
Misinterpretatie bij zowel gebruiker als ontwikkelaar beperken
Posted by Wout Lemmens in Interaction Design, Requirements on June 7th, 2011
Misinterpretatie bij zowel gebruiker als ontwikkelaar beperken
Requirements beschrijven waaraan een product moet voldoen, wat het biedt, welke randvoorwaarden er zijn, hoe het eruit gaat zien, voor wie het bedoeld is, hoe het gaat werken, etc. Maar het blijft een beschrijving, met als nadeel dat iedereen die het leest een eigen interpretatie heeft.
Bij de meeste projecten worden diverse scenario’s met de eindgebruiker of de klant nagespeeld om te bepalen of de specificatie aansluit bij de verwachting. Dit naspelen maakt het voor een eindgebruiker inzichtelijk, aangezien het simuleren en visualiseren van het beoogde gedrag veel meer tot de verbeelding spreekt. En dit voorkomt dat de eindgebruiker een eigen interpretatie maakt van de specificatie. Zoals beschreven in een blog van Karl O’Brien over ‘Requirements are done…‘: “It is like watching a movie versus reading the book, everyone can interpret a book in many ways.”.
Echter stopt het vaak bij de simulaties voor de eindgebruikers, terwijl dezelfde manier van visuele simulatie ook voor de ontwikkelaars en testers van groot belang is. Kans op misinterpretatie bij een eindgebruiker is nu beperkt, maar bij de ontwikkelaars en testers is de kans daarop nog steeds erg groot. Resultaat: het product wordt ontwikkeld met de misinterpretatie en sluit nog steeds niet aan bij de eindgebruiker, tot groot onvrede. Want per slot van rekening heeft de gebruiker tijd geïnvesteerd in validatie, maar ziet deze daar onvoldoende van terug.
Werkwijze
Hoe kun je dit concreet vormgeven, zodat naast gebruikers ook de ontwikkelaars en testers hierin meegenomen worden? Enkele voorbeelden van technieken:
Applicatie-flow
De applicatie-flow bevat schermschetsen van alle flow onderdelen, en deze zijn in de juiste volgorde geplaatst en met pijlen aan elkaar gekoppeld. Zo is er inzicht te krijgen in hoe de applicatie gaat werken.
Bij een van onze projecten hebben we de complete applicatie-flow uitgeprint en groot aan de muur gehangen. Wanneer er een nieuw onderdeel door de ontwikkelaars opgepakt werd, kon de werking daarvan goed uitgelegd worden aan de hand van de applicatie-flow. Ook bij onduidelijkheden waren de ontwikkelaars met regelmaat bij de applicatie-flow-muur te vinden.
Webflow aan de muur
Paper prototypen
Paper prototyping stelt ons in staat om heel snel ideeën te verifiëren met klanten en gebruikers. Zoals de term al suggereert wordt het prototype van de software gemaakt van papier, gebruikmakend van bijvoorbeeld PostIt notes, gekleurd papier, schaar en markers. Maar ook het tekenen of knippen/plakken van schermelementen kan goed werken. De verschillende schermonderdelen worden in papier uitgevoerd en op het ’scherm’ (een vel papier of het bureaublad) geplaatst. Vervolgens kan de gebruiker met de ’software’ gaan werken. Wij zijn de ‘computer’, en reageren op de acties van de gebruiker zoals de software het uiteindelijk ook zou gaan doen. Deze manier van werken is goed om te valideren bij een klant, en de uitkomst kan vervolgens via het paper prototype aan engineers getoond worden.
Paper prototype
Wire frames
Het visualiseren van concepten in schetsmatige schermen dwingt ontwikkelaars beslissingen te nemen over functionaliteiten en structuur, en brengt problemen in een vroeg stadium aan het licht. De visualisaties maken het ook mogelijk om de concepten te communiceren naar mensen buiten het team, bijvoorbeeld klanten of gebruikers.
Tenslotte vormen visualisaties zeer expliciete ontwerpdocumentatie; een goede serie (eventueel pixel-perfect) schetsen laat engineers weinig te raden over.
Wire frames als flow diagram
Simulaties
Veel van het gedrag kan via de bovenstaande manieren inzichtelijk gemaakt worden. Maar het blijft bijzonder moeilijk om interactie aspecten via statische plaatjes duidelijk te maken of tekstueel te beschrijven, laat staan dat gebruikers en ontwikkelaars het vervolgens juist kunnen interpreteren.
Door simulaties in te zetten kan met een clickable prototype, video of animatie veel beter bepaald worden of een interactie aspect werkt zoals het bedacht is. Enerzijds kan aan gebruikers getoond worden hoe bepaald gedrag zal gaan werken, en anderzijds is het ook uitermate geschikt voor engineers om het beoogde gedrag correct te implementeren.
Voordeel
Deze technieken voorkomen of beperken misinterpretatie, niet alleen bij de eindgebruikers, maar ook bij de ontwikkelaars en testers. De hele ontwikkelketen dient dit inzicht te hebben, want “de ketting is zo sterk als de zwakste schakel”.
Who writes my user stories
Posted by Albert Oudenampsen in Requirements, Uncategorized on July 19th, 2010
The user story is one of the useful initiatives that came out of the Agile movement. It expresses a very specific user need. Usually it’s written in just a few sentences in the language of the users. So any user and developer should be able to read a user story and immediately understand it.
User stories gained popularity after realizing that developers had to start working with users throughout the project to understand their needs. It certainly works better than letting a developer discuss the needs with a user, which tends to end after a few minutes in a “Yes, I get it! No worries, know what you need”, followed by a near endless code-and-fix cycles.
So user stories are great, but who writes them? Hmmm, users probably. After all it’s their story. Question is “can users write user stories”? The answer is simple: it depends….
Certainly some users can write user stories. Sysadmins can, helpdesk and application support too. But the “real” users, can they write user stories? I don’t know about that. When you leave the writing of user stories in the hands of the users that can write user stories you may end up with “unbalanced systems” like the ones in the famous what-if-airplanes picture. After all, you don’t build a system just to do application support or system admin (unless that is your business). You build systems to increase “business value” or whatever greater purpose and for that you need the “real” users.
As stated before: “any user and developer should be able to read a user story and immediately understand it”. If it is that simple, it cannot be too hard to learn how to write a user story.
A user story consists of two parts:
-Just a few lines of text that describe the problem;
-A Test that serves as an example and that can be used to determine when a story is complete.
A simple template for this can be found here: cukes.info
All very simple, and I bet it is possible to make a training course with exercises were the stories and their tests just drip of the table….
Unfortunately, most systems we build nowadays are not that simple. Recently I explained user stories to a group of barristers who were asked to describe their new system. After the theoretical part it was time for some their first user story. Not some lab example a real life one.
Barrister: how do we start?
Me: just go over the things you do during the day and see where your new system system comes in
Barrister: I visit people with a legal document, hand it over, explain the implications and sometimes I give them advice or propose a solution. Then I make notes on their file. That’s it.
Me: Hmmm, that is too simple, there must be more…..
The discussion continued for quite some time and finally we found that the user story was about efficiency. In the morning they receive a pile of documents for that day, they order them by address, program their navigation system and they make their visits.
Or the cukes.info template:
In order to make as many visits as possible during a day
As a barrister
I want to receive an daily workload optimized for traveling time and in such a way that I spend the least possible time in programming my navigation system.
Barrister: not in a million years I would have come up with this user story! And how do I write a test for this? Is the navigation system part of the whole system? And what if there are traffic jams or rush hours should that be in there too? And what about different makes of navigation systems?
My conclusion: help your users in writing user stories and certainly help them in writing test scenario’s.