Toetsvoorbereiding d.m.v. opdrachten - Validatietechnieken

10 belangrijke vragen over Toetsvoorbereiding d.m.v. opdrachten - Validatietechnieken

Welke vragen moet door de requirementsanalist worden beantwoord in de validatiestap?

  1. Zijn de requirements op een correcte manier opgeschreven?
    • Zijn ze juist, volledig en consistent?
  2. Verwoorden de requirements alle behoeftes van de gebruiker?
    • Dekken ze de essentiële behoeften van de belanghebbenden af?
  3. De validatie wijkt af van de Analyse omdat:
    • Requirements bij Analyse nog in informele wel formeel en gestructureerd)
    • De nadruk ligt:
      • a) Bij analyse: bepalen van wat de requirements zijn.
      • b) Bij validatie: vaststellen van de juistheid, volledigheid en consistentie van de requirements.

Wat is nodig bij de validatie van requirements en leg uit wat het inhoud?

  • Requirementsdocumenten
    • Een stabiele versie die voldoet aan de standaarden van de organisatie.
  • Kennis v.d. Organisatie
    • Impliciete kennis vd organisatie is basis requirements
  • Standaarden
    • Is voldaan aan standaarden die binnen de organisatie gelden?
  • Lijst van issues
    • Problemenlijst, liefst gesorteerd op type probleem
  • Afgesproken acties
    • Actielijst met betrekking op de gevonden problemen

De hele set van requirementdocumenten met de niveaus business-, gebruikers- en systeemrequirements moet op 3 manieren consistent zijn:

  1. Binnen 1 niveau moeten de requirements consistent zijn (bij. Functionele eisen met niet-functionele eisen en definities)
  2. De requirements op een niveau moeten consistent zijn met de requirements op een hoger niveau, waarvan ze een invulling zijn.
  3. De requirementsdocumenten moeten consistent zijn met overige documenten, zoals de business case en procesbeschrijvingen.
  • Hogere cijfers + sneller leren
  • Niets twee keer studeren
  • 100% zeker alles onthouden
Ontdek Study Smart

Leg de eis 'uniek identificeerbaar' uit voor een requirement

Om eenduidig te kunnen verwijzen naar een specifieke requirement moet elke requirement een unieke identificatie hebben.
Meestal een nummer of een combinatie van een lettercode en een nummer, bij. 3.2.1 of B23

Leg de eis 'atomair' uit voor een requirement

Een requirementsaanduiding mag niet meer dan één eis of beperking bevatten.
Als de zin nog op te splitsen is in delen dan opsplitsen.
Bij. [REQ12]: 'Het systeem biedt de gebruiker schermen om in- en uit te loggen' moet opgesplitst worden in:
[REQ48]: 'Het systeem bevat een scherm om in te loggen'
[REQ49]: 'Het systeem bevat een scherm om uit te loggen'

Leg de eis 'eenduidig' uit voor een requirement

Elke requirement mag maar op één manier geïnterpreteerd kunnen worden:
Daarom:
  • Gebruik geen formuleringen die zaken open laten, zoals 'nog te bepalen'
  • Gebruik geen termen die meerdere betekenissen hebben, zoals 'scherm' voor een computerscherm of een 'window' in een applicatie.
  • Beschrijf altijd wie een actie uitvoert, zoals 'de gebruiker', 'het systeem'.
  • Voorbeeld: 'De systeembeheerders kunnen nieuwe gebruikers toevoegen. Deze hebben de rechten om tabellen te maken.' Wie zijn deze'?

Leg de eis 'grammaticaal correct' uit voor een requirement

Requirements moeten volledige zinnen zijn die geen spel- of grammaticafouten bevatten.

Voorbeeld: 'De knoppen "Ok" zijn pas in te schakelen als alle velden ingevuld zijn'.
  • Is dit een taalfout? (meervoud ipv enkelvoud)
  • Is de analist vergeten de tweede knop in de zin op te nemen?  

Leg de eis 'Traceerbaarheid' uit voor een requirement

Elke requirement moet traceerbaar zijn naar het hogere en het lagere niveau van requirements. Uit één businessrequirement komen vaak meerdere gebruikersrequirements voort en daaruit weer meerdere systeemrequirements.
Traceerbaarheid is nodig, zodat bij wijzigingen de gevolgen voor de overige requirements gemakkelijk kunnen worden nagegaan.
Ook moet andersom de bron of motivatie bekend zijn, zodat vragen over het requirement nagegaan kunnen worden.

Leg de eis 'testbaar/verificeerbaar' uit voor een requirement.

De uiteindelijke test van het geïmplementeerde systeem vindt plaats op basis van de requirements.
Als is vastgesteld dat aan alle requirements is voldaan, wordt het systeem als 'af' beschouwd. Dus  moet het mogelijk zijn voor elke requirement vast te stellen of het vervuld is.
Dus moet iedere requirement opgesteld zijn in duidelijk, meetbare en begrensde vorm.
Gebruik dus geen woorden als 'goedkoop', 'minimaliseren', 'ongeveer' of 'sneller dan'.
Een business- of gebruikersrequirement hoeft niet per se verifieerbaar te zijn, mits de systeemrequirements wél allemaal verifieerbaar zijn.

Leg de eis 'Voorzien van prioriteit' uit voor een requirement

Voor elke requirement moet vastgesteld zijn wat de prioriteit van het requirement is.
Dat is nodig om te kunnen bepalen welk requirement als eerste gerealiseerd moet worden.

De vragen op deze pagina komen uit de samenvatting van het volgende studiemateriaal:

  • Een unieke studie- en oefentool
  • Nooit meer iets twee keer studeren
  • Haal de cijfers waar je op hoopt
  • 100% zeker alles onthouden
Onthoud sneller, leer beter. Wetenschappelijk bewezen.
Trustpilot-logo