8/25/2023

Introductie requirements

Agenda
Inleiding requirements & requirements engineering
Model van Kano
Communicatie en - problemen
Modellen
Reviews & intake testbasis
Traceerbaarheid & wijzigingen
Aan de slag met requirements

2
 8/25/2023

Vraag:
Wat is een requirement?

Wat is een requirement?

1. Een voorwaarde of mogelijkheid die een gebruiker nodig heeft voor
het oplossen van een probleem of het bereiken van een doel

2. Een voorwaarde of mogelijkheid die een systeem of

systeemcomponent moet bieden om te voldoen aan een contract,
standaardspecificatie of ander formeel opgelegd document

3. Een gedocumenteerde weergave van een voorwaarde of

mogelijkheid zoals is gesteld in (1) of (2)

[IEEE Std. 610.12-1990]

4
 8/25/2023

Soorten requirements
1. Functionele requirements
• Wat het systeem moet doen

2. Kwaliteitsrequirements
• Hoe het systeem dat
Niet-functionele requirements
moet doen
(“Non-functionals”)

3. Beperkingen (”constraints”)
• Aan het systeem opgelegd
door de omgeving

6
 8/25/2023

Functionele requirements
Een functionele requirement is een requirement met
betrekking tot een resultaat dat door een functie van het
systeem moet worden geleverd of het gedrag dat moet
worden vertoond

Kwaliteitsrequirements
Een kwaliteitsrequirement is een requirement dat
betrekking heeft op een kwaliteitskenmerk dat niet door
de functionele requirements wordt afgedekt

8
 8/25/2023

Beperkingen = constraints
Een beperking is een requirement dat de oplossings-
ruimte beperkt waarbinnen de gegeven functionele en
kwaliteitsrequirements kunnen worden gerealiseerd

Requirements in V-model

wens, wet,
beleid, kans, gebruik &
probleem beheer

requirements
acceptatie
tests
functioneel
Accepterende
ontwerp
partij

technisch
systeem tests
ontwerp
Leverende partij
Ontwikkel/unit
realisatie
tests

10
 8/25/2023

Requirements in agile context

Planning

Testen Requirements
Planning

Planning
Bouw Design Testen Requirements

Testen Requirements
Bouw Design

Bouw Design

11

Vraag:
Wie of wat bepaalt de
requirements?

12
 8/25/2023

Systeemcontext

Gebruikers
Systeem
Bedrijfsproces Systeem

Hardware
Document

13

Voorbeeld van een context diagram

Interactie Output aan Ander

systeem
Persoon

Ander Input vanuit

systeem Systeem
System

Data, goederen

Context Persoon

Irrelevante omgeving
14
 8/25/2023

De requirementsanalist
De requirementsanalist is een persoon die – in samen-
werking met de belanghebbenden – requirements
eliciteert, documenteert, valideert en managet

De requirementsanalist heeft een

centrale rol in het ontwikkelproces
en is het primaire aanspreek-
punt voor de belanghebbenden,
architecten, bouwers en testers

15

Requirements engineering
Requirements engineering is een systematische en gedisciplineerde
aanpak voor het specificeren en beheren van requirements met de
volgende doelen:

1. De relevante requirements kennen, hierover overeenstemming

bereiken tussen de belanghebbenden, ze documenteren volgens
vastgestelde standaards en ze systematisch beheren

2. De behoeften en wensen van de belanghebbenden begrijpen en

documenteren

3. Het risico beperken van de oplevering van een systeem dat niet
voldoet aan deze eisen en wensen

16
 8/25/2023

Requirements engineering (2)

Feiten en cijfers volgens onderzoeken naar software
projecten
• 60% van alle fouten ontstaan in de fase
requirementsengineering
• Onduidelijke, onvolledige of ontbrekende requirements
leiden tot systemen die niet voldoen aan de behoeften van
de gebruikers
• De meeste fouten in requirements worden pas laat in het
project of zelf na oplevering tijdens het gebruik ontdekt
• Hoe later een fout wordt ontdekt, des te duurder is het om
de fout te herstellen

17

Requirements engineering (3)

Goede requirementsengineering is de basis voor de
succesvolle ontwikkeling van systemen die voldoen
aan de behoeften van de klant

Onvoldoende requirementsengineering leidt tot

• onduidelijke
• onvolledige requirements
• ontbrekende

18
 8/25/2023

Activiteiten

Eliciteren
Prioriteiten

Traceerbaarheid

Managen
Documenteren
Wijzigingen

Valideren & Versies

onderhandelen

Zie ISO/IEC/IEEE 29148:2011

19

Software Development Life Cycles

De positie van requirementsengineering verschilt tussen
procesmodellen voor systeemontwikkeling

In sequentiële modellen (Waterval, V-model) wordt

requirementsengineering gezien als een aparte vroege
projectfase vóór ontwerp en bouw

In incrementele en iteratieve modellen (XP, Agile)

worden requirements meegenomen bij iedere
ontwikkelstap en is requirementsengineering een
continu meelopend proces in alle ontwikkelfasen

20
 8/25/2023

Training voor requirements engineering

IREB Certified Professional for Requirements
Engineering

- Foundation Level -

21

Agenda
Inleiding requirements & requirements engineering
Model van Kano
Communicatie en - problemen
Modellen
Reviews & intake testbasis
Traceerbaarheid & wijzigingen
Aan de slag met requirements

22
 8/25/2023

Wat zijn de functies van een goede

mobiel
- Touchscreen
- Bellen
- Batterijduur
- Opladen van de batterij met kabel /
- Camera lightning usbc / (draadloos nice to
- AI – IoT have)
- Apple ecosystem
- Batterij die een week meegaat (solid state) - Speakers voor bellen
- Helemaal niet meer opladen - Mic
- Volumeregelaar
- Domotica

Oefening
- Blokkeer nummer functie
- Onbreekbaar glas - knop vergendelen/ontgendelen)
- Camera
- Kleur /momochroom
- Simcard
- Zaklamp
- Gps /Bluetooth/wifi/kabel
- Nfc (applepay)
- Ronde zijkanten
- Dikte minder dan een stroopwafel
- Past in zak
- Dataopslagruimte > 128
- Digitaal toetsenbord (US/D/NL
QWERTY/AZERTY)
- Siri/google assistent

23

Het model van Kano Delighters

Tevreden =WOW-factoren
klant
=onbewuste reqs
Satisfiers
=Prestatiefactoren
=bewuste reqs
Verwachting
overtroffen
Verwachting
niet vervuld Dissatisfiers
=Basisfactoren
= onderbewuste reqs

Teleurgestelde
klant

24
 8/25/2023

Agenda
Inleiding requirements & requirements engineering
Model van Kano
Communicatie en - problemen
Modellen
Reviews & intake testbasis
Traceerbaarheid & wijzigingen
Aan de slag met requirements

25

Grondbeginselen van communicatie

26
 8/25/2023

Oefening

27

Oefening - Wat staat hier?

Ik zeg niet dat hij die portemonnee van mijn vrouw heeft
gestolen.

28
 8/25/2023

Transformatie-effecten

Persoonlijke perceptie Persoonlijke kennis

Waarneming Weergave

Fouten?

Werkelijkheid Taal

29

Verschillende perspectieven

30
 8/25/2023

Oefening

31

Stijlregels voor requirements

Basisregels voor natuurlijke taal
• Korte zinnen
• Bij voorkeur in een actieve vorm
• Slechts één requirement per zin

32
 8/25/2023

Verklarende woordenlijst
• Context-specifieke technische termen
• Afkortingen
• Acroniemen
• Algemeen gangbare woorden die een specifieke
betekenis hebben in een bepaalde context
(bedrijfstaal)
• Synoniemen
• Homoniemen

33

Agenda
Inleiding requirements & requirements engineering
Model van Kano
Communicatie en - problemen
Modellen
Reviews & intake testbasis
Traceerbaarheid & wijzigingen
Aan de slag met requirements

34
 8/25/2023

De term “model”
Een model is een abstractie van een bestaande of te
creëren werkelijkheid

Eigenschappen en voordelen van modellen

• Afbeelding van de werkelijkheid
- Beschrijvend (bestaande werkelijkheid)
- Voorschrijvend (fictieve werkelijkheid)
• Reductie van de werkelijkheid
- Selectie (alleen relevante aspecten)
- Samenvatting (van bepaalde aspecten)
• Pragmatisch
- Bepaald doel
- Bepaalde context

35

Conceptuele modellen
Diagrammen die een bepaald aspect van de software
weergeeft, bijvoorbeeld:
• Data/gegevens
• Functioneel
• Gedrag/status
Vaak UML – Unified Modeling Language

36
 8/25/2023

Use case diagram voorbeeld

Factuursysteem
Zend factuur
EP: > €1000
klant Chef
<<extend>>

<<Actor>> Status
Betalingen navraag
<<include>>
Leg
<<Actor>>
verkoop
Voorraad
vast Verkoper

37

Entiteit–Relatie Diagram – voorbeeld

Naam

Factuurnummer
Prijs

Factuur Product

Bevat
N M

38
 8/25/2023

UML klassediagram – voorbeeld

Factuur Tastbaar Dienst

goed
Factuur #
Bestel- Tariefeenheid
Printen, hoeveelheid
verzenden

1 .. *
1
Algemeen Orderregel Product
(kop)
0 .. * Betreft 1 Naam, prijs
Adres Regelnummer gefactureerd verkocht
BTW Bestellen ,
Totaalbedrag verkopen

39

UML activiteitendiagram – Voorbeeld

[Nieuwe klant]

Registreer Verkoop- Registreer Klant-

verkoop info klant info
Verkoper

Werk Product-
voorraad bij info

Verstuur
Chef

factuur

40
 8/25/2023

Wireframes
Bouwtekening van de website
Interactie-ontwerp
Niet mooi, geen kleur
Gebruiksvriendelijkheid of usability
Waar zit welk element
(bron: Wikipedia)

41

Mock-Up
Toont hoe het er straks moet uitzien
Lijkt erg op wat het moet worden, maar werkt niet
Gebruikt voor demonstraties, lessen, evaluaties of
promotie.

Schets Wireframe Mock-up Prototype

42
 8/25/2023

Prototypes
Werkend model
• Beschouwd als meest effectieve methode om fouten in
requirements te vinden

Twee soorten
• Wegwerp
Niet onderhouden na gebruik
• Evolutionair
Verder ontwikkeld en verbeterd in latere stappen

Beperkte scope
• Vereenvoudigd, net genoeg detail voor validatie

43

Personas

Jean Pol
Woonplaats: Deventer Jean is al 15
jaar de
Leeftijd 35 jr
beste speler
Beroep: Coach van …
Privé: getrouwd, 2 kinderen lees meer…

“Ik wil van alle spelers hun voorkeurs

behoeften doelstelling werkt graag pijnpunten

met

44
 8/25/2023

Oefening

45

Agenda
Inleiding requirements & requirements engineering
Model van Kano
Communicatie en - problemen
Modellen
Reviews & intake testbasis
Traceerbaarheid & wijzigingen
Aan de slag met requirements

46
 8/25/2023

Reviewen van requirements of testbasis

Het vaststellen van de testbaarheid van de testbasis
met betrekking tot
• Volledigheid
• Consistentie
• Toegankelijkheid
• Vertaalbaarheid naar testgevallen

Het zo vroeg mogelijk vinden van kostbare fouten

• Defects

47

De kosten van fouten

Böhm

RQMS SPEC DSGN CODE IMPL MAINT

48
 8/25/2023

Voordelen van reviews

Vroegtijdige fout detectie
Nu een ‘major’ fout vinden en oplossen bespaart negen
reparatie uren later in het proces
Minder fouten in productie
Kortere ontwikkeltijd
Minder testkosten
Verbeteren van de productiviteit in ontwikkelen
Vergroten van de kennis van de applicatie

49

Reviewtypen
Verschillende technieken, gewoonlijk aangeduid als
review
• Informele review= peer review = beoordeling = expert
review
• Technische review
• Checklist review
• Walkthrough (kennisoverdracht of inspectie-light)
• Inspectie = formele review
• Lezen vanuit een specifiek perspectief
• Prototyping

50
 8/25/2023

Hoe dragen testers bij aan reviews

Testers zijn experts in het ontdekken van
tegenstrijdigheden, vaagheden, omissies, afwijkingen,
et cetera
Testers vinden vroeg fouten vinden belangrijk
Bij de tester komen alle niveaus van requirements
samen
Dus testers kunnen bijdragen aan de kwaliteit
Goede requirements maken een efficiënt en effectief
ontwikkelings- en testtraject mogelijk

51

Reviews leveren op
Veranderingen in het product
Wijzigingen in regels checklists en/of brondocumentatie
Procesverbetering
• Reviewproces
• Ontwikkelproces
Metrieken (alleen formele reviews)

52
 8/25/2023

Reviewen en goede requirements

Een goede review:
• Leidt niet tot goede requirements…
• Leidt niet naar goede code…
• Leidt niet naar foutvrije software…
• Leidt niet naar onbelemmerd testen …
• Leidt niet naar…

Hoe kan dat??

53

Oefening – wie heeft gelijk?

54
 8/25/2023

Review als activiteit in testen

Reviews (intake testbasis) van invloed op planning van
testen
Testbasis is beschikbaar en gefixeerd
Deelname review of inspectie uitermate geschikt als
intake moment

55

Moment van intake testbasis – V model

wens, wet,
beleid, kans, gebruik &
probleem beheer
Input voor

requirements
acceptatie
tests
Testbasis functioneel
ontwerp

technisch
systeem tests
ontwerp

ontwikkel
realisatie
tests

56
 8/25/2023

Moment van intake testbasis –

iteratief/incrementeel model

Planning

Testen Requirements
Planning

Planning
Bouw Design Testen Requirements

Testen Requirements
Bouw Design

Bouw Design

57

Agenda
Inleiding requirements & requirements engineering
Model van Kano
Communicatie en - problemen
Modellen
Reviews & intake testbasis
Traceerbaarheid & wijzigingen
Aan de slag met requirements

58
 8/25/2023

Traceerbaarheidsrelaties

Traceer-
baarheid
tussen
requirements

Bronnen Toepassingen
Requirements
(voorafgaand) (opvolgend)
Pre-RS Post-RS
Bijv. Bijv.
traceer- traceer-
beleid, ontwerp,
baarheid baarheid
risico test case,
release

59

Wijzigingsbeheer van requirements

Wijzigingen in requirements komen voor tijdens de gehele
levenscyclus van het systeem en worden gemanaged in
wijzigingsbeheerproces

Allerlei wijzigingen treden op

• Nieuwe requirements worden toegevoegd
• Bestaande requirements worden aangepast
(en het versienummer opgehoogd)
• Achterhaalde requirements worden verwijderd

Wijzigingen zijn op zich niet negatief

Veelvuldige wijzigingen zijn vaak het gevolg van tekortkomingen in het

ontwikkelproces

60
 8/25/2023

Wijzigingscommissie
De wijzigingscommissie is verantwoordelijk voor het
behandelen van ingediende wijzigingsverzoeken
Mogelijke leden:
Change manager
Contractor
Gebruikersvertegenwoordiger
Architect
Requirementsanalist
Ontwikkelaar
Kwaliteitsmanager

61

Agenda
Inleiding requirements
Systeem en systeemcontext
Communicatie - Natuurlijke taal
Communicatie - Modellen
Reviews & intake testbasis
Traceerbaarheid

62
 8/25/2023

TIJD OM TE OEFENEN!

63

64

64