Question 1
Question
Richtlijn 1:
Redundatie: twee of meer requirements verwoorden hetzelfde.
Question 2
Question
Richtlijn 1:
Als je een requirement verwijderd, dan mag je het nummer hergebruiken.
Question 3
Question
Richtlijn 1:
De nummering geeft het altijd totaal aantal requirements weer.
Question 4
Question
Richtlijn 1:
Het is verstandiger om bij requirements nummers te gebruiken als: 1.1 - 1.2.a. Dit is makkelijker te communiceren.
Question 5
Question
Richtlijn 2:
Discussie over onduidelijkheden in een requirement voorkom je door requirements in de active vorm (met een onderwerp) te formuleren.
Question 6
Question
Formuleer een requirement met veel informatie, in plaats van bondig. Zo weet de gebruiker gelijk aan de requirement wat je wilt
Question 7
Question
Richtlijn 3:
De belang van een requirement is altijd: belangrijk, essentieel of gewenst.
Question 8
Question
Richtlijn 3:
De toegevoegde kolom (waarin het belang van een requirement wordt aangegeven) in een requirementlist wordt "Attribuut" genoemd.
Question 9
Question
Richtlijn 3:
Met een attribuut wordt extra informatie toegevoegd aan een requirement. ZONDER dat het requirement textueel wijzigt.
Question 10
Question
Richtlijn 3:
Probeer woorden als: "moeten", "mogen", "liefst" en "dienen" te vermijden bij het opstellen van een requirement. Neem deze begrippen op als attribuut.
Question 11
Question
Richtlijn 3:
Gebruik geen voorbeelden in een requirement. Maar zet voorbeelden in een aparte kolom "attribuut".
Question 12
Question
Richtlijn 3:
In een requirement mag je ook uitleg geven op de betekenis van een woord als het niet duidelijk is.
Question 13
Question
Richtlijn 3:
Je mag bij het formuleren van een requirement GEEN motivatie erbij zetten.
Question 14
Question
Richtlijn 4:
Het koffiezetapparaat heeft een thermoskan. Dit beschrijft de behoefte.
Question 15
Question
Richtlijn 4:
Met de vraag "Waarom moet het apparaat deze oplossing hebben" krijg je de werkelijke behoefte van een requirement.
Question 16
Question
Richtlijn 4:
Het probleemdomein richt zich op de behoefte en het oplossingsdomein richt zich op de oplossing.
Question 17
Question
Richtlijn 4:
De "waarmee" vraag geeft de oplossing voor de behoefte.
Question 18
Question
Richtlijn 4:
De "Waarom" vraag geeft de behoefte achter de oplossing.
Question 19
Question
Richtlijn 4:
Oplossingen in een requirement zijn te herkennen aan het gebruik van zelfstandig naamwoorden. (timer)
Question 20
Question
Richtlijn 5:
Schrijf bondige zinnen die het liefst meerde behoeftes verwoorden.
Question 21
Question
Richtlijn 5:
Automaire Requirements: zijn requirements die maar één behoefte verwoorden.
Question 22
Question
Richtlijn 5:
De volgende requirement is goed: "De kwast kan verf aanbrengen en kan vaker gebruikt worden."
Question 23
Question
Richtlijn 5:
"Het koffiezetapparaat kan minimaal 12 kopjes koffie zetten." Is goed geschreven.
Question 24
Question
Richtlijn 5:
Iedere requirement is even belangrijk.
Question 25
Question
Richtlijn 6:
Het is toegestaan om vaagheden(snel,veel) te gebruiken in je requirements. Dat is zelfs goed, want je maakt de essentie ermee duidelijk.
Question 26
Question
Richtlijn 6:
Identificeer vaagheden met <....>. Zo is duidelijk dat hier getallen of andere eenheden worden toegevoegd.
Question 27
Question
Richtlijn 6:
De vage begrippen tussen de haken <...> kunnen twee dingen verwoorden. Een kwantificering en één of meerdere substellingen.
Question 28
Question
Richtlijn 6.
Als je in je requirement een vaagheid(snel) gebruikt. Dan MOET je deze uitwerken.
Question 29
Question
Richtlijn 6.
Requirements die verwoorden waaraan iets NIET moet voldoen zijn toegestaan. Maar dan moet je wel in de substelling verwoorden wat WEL moet.
Question 30
Question
Richtlijn 7.
Kwantificeren betekend: uitdrukken in getal en eenheid.
Question 31
Question
Richtlijn 7.
Een gekwantificeerde vaagheid, is geen onderdeel van een requirement. De kwantificering krijgt daarom ook een unieke aanduiding (eigen nummer).
Question 32
Question
Richtlijn 7.
Een kwantificering geeft antwoord op de "hoe <vaagheid>".
Question 33
Question
Richtlijn 7.
Het kwantificeren van een requirement is hetzelfde als het meetbaar maken van een requirement.
Question 34
Question
Richtlijn 7.
Kwantificeren maakt het requirement specifieker.
Question 35
Question
Richtlijn 8.
Substelling zijn requirements, die je op hun beurt kunt uitwerken in substellingen en kwantificering.
Question 36
Question
Richtlijn 8.
Bij het uitwerken van vage termen mag je de oplossing beschrijven.
Question 37
Question
Richtlijn 9.
Naast "functies" en "kwaliteiten" zijn er ook "regels".
Question 38
Question
Richtlijn 9.
Functies worden ook wel "functional requirements" genoemd. En kwaliteiten "non- functional requirements".
Question 39
Question
Richtlijn 10.
Houd bij een requirement de woordkeuze beperkt. Gebruik bijvoorbeeld niet telkens iets anders (beker, glas, kopje)
Question 40
Question
Richtlijn 10.
Een afgesproken beperkte woordenschat heet ook wel: Compromised Language
Question 41
Question
Richtlijn 11.
Glossary = een verklarende woordenlijst.
Question 42
Question
Richtlijn 12.
Een gezichtspunt is ook een requirement.
Question 43
Question
Richtlijn 12.
Inventariseer eerst welke gezichtspunten belangrijk zijn, en stel daarna pas de requirements daarbij op.
Question 44
Question
Richtlijn 12.
De ISO 9126 standaart, is een overzicht van goed opgestelde requirements.
Question 45
Question
Richtlijn 12.
COPAFIJTH is een overzicht van gezichtspunten.
Question 46
Question
Richtlijn 13.
Met Proza maak je duidelijk: in welke situatie de lezer zich het beste kan inleven.
Question 47
Question
Richtlijn 13.
Proza verwoord helder de context waar de requirements betrekking op hebben.
Question 48
Question
Richtlijn 13.
De inleidende text (Proza) mag voorbeelden van requirements bevatten.
Question 49
Question
Richtlijn 14.
De combinatie van belang en urgentie bepaald de prioriteit van een requirement.