Opdracht
Groeidocument opdracht 2.1: requirements en user stories Op basis van wat je weet van de doelgroep en behoeftes en activiteiten maak je een eerste beschrijving van de mogelijke user stories. Werk ten minste 5 user requirements uit in user stories.
Opdracht
Groeidocument opdracht 2.2: use cases Aan de hand van de user stories uit opdracht 2.1 werk je user stories uit in één (of meer) use case diagram(men).
Requirement beschrijving
- User requirement: de bepaling van wat het product of dienst moet opleveren voor de gebruiker
- Technische requirement: enkelvoudig gedocumenteerde bepaling, wat een bepaald product of dienst zou moeten doen
Waarom requirements?
- Minder fouten in requirements = minder fouten tijdens gebruikname = minder herstelwerk gedurende het ontwikkeltraject
- Sneller ontwikkeltraject
- Minder miscommunicatie tijdens het project
- Minder verandering in de scope
- Beter te beheren en ordelijk verlopend project
- Efficiënter testtraject
- Hogere tevredenheid van ontwikkelaars, testers, gebruikers en overige belanghebbenden
User stories
Een user story is een manier om een scenario vast te stellen door de behoefte van de gebruiker te beschrijven. Het bezit de acceptatiecriteria. Het beschrijft de context en word vaak gebruikt in software development.
Het bestaat uit 3 delen: Voor wie doe je het? Wat doe je? Waarom wil je het hebben?
Let op
Een user story stelt niet de oplossing vast, puur het scenario. Let op dat je niet de oplossing opschrijft
User story criteria
Je weet of je user story goed is als het de volgende acceptatiecriteria heeft:
- Meetbaar: Er is een waarde of uitkomst gedefinieerd.
- Specifiek: Het moet kloppen voor de context waarbinnen de story geldig is
- Concreet: Helder voor iedereen in het team
- Testbaar Het moet duidelijk zijn dat het herhaalbaar is onder de gegeven omstandigheden.
User story voorbeeld
“Als huiseigenaar met een grote tuin wil ik mijn gazon op een snelle en makkelijke manier kunnen maaien zodat ik daar weinig tijd mee kwijt ben.”
Welke criteria zal hiervoor nodig zijn? (let op: geen oplossing schrijven) Het kunnen dingen zijn zoals:
- De oplossing is geschikt voor minstens 100 m2 gras in 20 minuten.
- Het is te bedienen voor mensen zonder enige ervaring in de omgang met machines.
- Geschikt voor wekelijks gebruik.
- Gemaaid gras hoeft niet opgevangen te worden maar mag blijven liggen.
Aanvullende context die je opgehaald hebt is:
- De tuin is namelijk erg groot
- De huiseigenaar is niet begaan met technologie en vind alles wat digitaal is maar niks
Interpretatie ruimte
Let op dat er geen ruimte is voor interpretatie in je user story. Ook al lijkt het doel hetzelfde.
Oefening
“Als zorgverlener, wil ik inzicht in de medicatiehistorie van de patiënt, zodat ik bij twijfel de nieuw voorgeschreven dosering gemakkelijk kan verifiëren.”
Een aantal criteria zijn:
- Medicatiehistorie: Hoe lang moet je terug gaan?
- Overzicht over de patiënt: Hoe kan ik het overzicht over de patiënt houden
Use case diagram
Een use case, vergeleken met een user story, is het een gedetailleerde representatie van hoe het systeem zou moeten werken. Het brengt verschillende requirements en user stories bij elkaar en laat de samenhang tussen de verschillende elementen doormiddel van interacties. Het bestaat uit: Requirements: wat het systeem moet doen Gebruikers: hun behoeften en activiteiten (taken) Interacties hoe het systeem regeert op de gebruikers acties of ‘vragen’.
Een diagram is een visuele representatie van het systeem. Je wilt weten: Wie moet er iets met mijn systeem en waarmee zijn ze verbonden? Je creëert een web van gebruikers(actors), cases (in een bepaald systeem), en de verbindingen (wie gebruikt welke case).
Niet alle use cases zijn even groot, sommige interacties zijn klein, maar nogsteeds belangrijk. Let op dat je niet dingen op schrijft als “ik druk op de inlog knop”, maar niet te algemeen zoals “ik wil het systeem gebruiken”.
Voorbeeld diagram
Een diagram heeft 3 hoofd onderdelen: Actors: gebruikers van het systeem, kan computers of personen zijn, die met het systeem omgaan. Word meestal getekend als een poppetje. Use cases: Use cases vertegenwoordigen specifieke functionaliteiten. Dit kunnen dingen als systemen zijn. Word getekend als een gekleurd vlakje met een label. Relaties: De lijnen en pijlen die actoren en gebruiksscenario’s in het diagram met elkaar verbinden. Geeft aan hoe actoren met de cases in het systeem omgaan.
Diagram actor
Een actor staat altijd buiten een systeem. Het gaat om met dingen in het systeem. Een actor staat dus altijd buiten het systeem.
Voorbeeld
Een aantal use cases zijn bijvoorbeeld:
- De basis use case van het systeem fiets is een stukje fietsen. Hier heb je een fiets nodig
- Je moet kunnen remmen
- Als het donker is moet je je verlichting aan doen
- Als je een lekke band hebt wil je die repareren Een actor kan de fietser zijn. Deze gaat om met al deze cases. Een andere actor kan een fietsenmaker staan. Deze kan bijvoorbeeld alleen omgaan met punt 4, en een nieuw punt:
- Groot onderhoud aan de fiets
Samenvatting
Om dus een recap te maken:
- Requirement(in de techniek): is een enkelvoudig gedocumenteerde bepaling, wat een bepaald product of dienst zou moeten doen.
- User story: definieert requirements vanuit de behoefte van de gebruiker, de waarde die het de gebruikers levert.
- Een user story beschrijft nooit de oplossing
- Acceptatie criteria specificeren wanner aan een requirement (user story) is voldaan.
- Acceptatiecriteria zijn: meetbaar, specifiek, concreet en testbaar.