Als freelance software developer werk ik aan de implementatie van requirements in maatwerk oplossingen. Denk daarbij aan SaaS-platformen, websites en webapplicaties op maat die aan eisen moeten voldoen. Tussen de wensen van de klant en de code die ik schrijf als developer, zitten: user stories, requirements & usecases. Deze zijn van belang om de klant tevreden te stellen.
User stories
Een user story is een korte beschrijving van wat een gebruiker van het systeem moet kunnen doen. Zo’n (eind)gebruiker, ook wel actor genoemd, heeft een bepaalde rol. Vanuit die rol wil de actor met een actie een doel bereiken. Een user story wordt beschreven in de vorm:
"Als [rol] wil ik [actie] zodat ik [doel]"
Voorbeeld:
"Als gebruiker wil ik mijn wachtwoord resetten zodat ik opnieuw kan inloggen als ik mijn wachtwoord ben vergeten."
Waarom user stories? Het opstellen van user stories levert de volgende voordelen:
- Identificeren van behoeften en wensen van actors
- Helpt met het opstellen van requirements en (deel-)taken zodat er een betere tijdsinschatting kan worden gemaakt.
- Het hebben van einddoelen: als het systeem is ontwikkeld, kan er worden geverifieerd of alle user stories worden vervuld (acceptatie). Zo kun je dan per user story het systeem langsgaan om te controleren of de gewenste actie kan worden uitgevoerd door een persoon in een bepaalde rol.
- Helpt het met het bouwen van geautomatiseerde testen.
Usecases
Usecases beschrijven hoe gebruikers het systeem gebruiken. Dit kunnen de stappen zijn die de gebruiker uitvoer om een doel binnen het systeem te bereiken. Overigens hoeven usecases niet per se tussen gebruiker en systeem plaatsvinden — het systeem kan ook reageren op andere soorten verzoeken. Bijvoorbeeld, een trigger vanuit een ander systeem.
Er zijn verschillende vormen waarop je een usecase kunt beschrijven. Hier is een voorbeeld van een usecase:
Usecase 1: Bewerken blogbericht
Primaire actoren: Admingebruiker
Korte omschrijving: De admingebruiker bewerkt een gedeelte van een bestaande blogbericht.
Precondities: De admingebruiker is ingelogd en gerechtigd om blogberichten te bewerken.
Postcondities: Wijzigingen aan het blogbericht staan online
Stappen:
1. Actor verzoekt om blogbericht te bewerken
2. Systeem toont invoerveld met alle velden van een bericht die bewerkt kunnen worden
3. Actor bewerkt bericht waar nodig
4. Actor geeft aan bericht op te slaan
5. Systeem voert wijzigingen door en updatet de laatst-bewerkt datum
Alternatieven:
4.[Veld is leeg]
4.1 Actor krijg een melding dat een bepaald verplicht veld leeg is
4.2 Actor kan veld alsnog invoeren
4.3 Terug naar stap 3
Faalscenario:
5.[Doorvoeren wijzigingen mislukt]
5.1 Systeem kan wijzigingen niet doorvoeren door een storing
5.2 Actor krijg een melding dat het opslaan is mislukt.
5.3 Einde usecaseDit is slechts een simpel voorbeeld. In de praktijk zijn er meerdere eigenschappen en details die je kunt toevoegen.
Uit een usecase zou je moeten kunnen halen wat het systeem allemaal kan. Laat dat nou handig zijn bij het identificeren van requirements.
Software requirements
In software engineering zijn requirements, of eisen, essentiële onderdelen die beschrijven wat het systeem moet bereiken of aan welke criteria het moet voldoen om als succesvolle oplossing te worden beschouwd.
We kennen functionele- en niet-functionele requirements.
Functionele requirements
Functionele requirements specificeren de gedragingen en functionaliteiten dat het softwaresysteem moet uitvoeren om te voldoen aan de behoeften van de gebruikers.
Ze worden doorgaans uitgedrukt in termen van gebruikersinteracties of systeemreacties en worden vaak gedocumenteerd met behulp van usecases, user stories of lijsten met functies. Dit kun je terugzien in het voorgaande usecase voorbeeld. Daar kunnen we namelijk de requirement uit halen dat het systeem de laatst-bewerkt datum moet bijwerken nadat een gebruiker een blogbericht bewerkt.
Niet-functionele requirements
Met behulp van niet-functionele eisen beschrijven we kwaliteitskenmerken van het systeem. Dit kan betrekking hebben op de user interface, snelheid, prestaties, security, gebruikersvriendelijkheid, enzovoorts.
Een voorbeeld van een niet-functionele eis is dat het systeem een blogbericht binnen 2 seconden moet opslaan voor een snelle gebruikerservaring.
Combinatie user stories, usecases & requirements
Door het combineren van user stories, use-cases en requirements kan ik als freelance softwareontwikkelaars en requirements engineer (actief in Arnhem) de wensen van mijn klanten gestructureerd omzetten in concrete features.
User stories helpen bij het begrijpen van de klantbehoeften, use-cases bieden gedetailleerde scenario's van het systeemgebruik, en requirements geven de richtlijnen voor ontwerp en ontwikkeling. Met deze aanpak kan ik als software developer efficiënt werken en op maat gemaakte oplossingen leveren die perfect aansluiten bij de wensen van de klant.
Deze benadering wordt typisch toegepast in agile omgevingen (Scrum), waarmee iteratieve ontwikkeling en nauwe samenwerking met de klant centraal staan. Door regelmatige feedback momenten kan er snel gereageerd worden op veranderende wensen van de klant.
