Requirements

Richtlijn 1:
Redundatie: twee of meer requirements verwoorden hetzelfde.

Richtlijn 1:
Als je een requirement verwijderd, dan mag je het nummer hergebruiken.

Richtlijn 1:
De nummering geeft het altijd totaal aantal requirements weer.

Richtlijn 1:
Het is verstandiger om bij requirements nummers te gebruiken als: 1.1 - 1.2.a. Dit is makkelijker te communiceren.

Richtlijn 2:
Discussie over onduidelijkheden in een requirement voorkom je door requirements in de active vorm (met een onderwerp) te formuleren.

Formuleer een requirement met veel informatie, in plaats van bondig. Zo weet de gebruiker gelijk aan de requirement wat je wilt

Richtlijn 3:
De belang van een requirement is altijd: belangrijk, essentieel of gewenst.

Richtlijn 3:
De toegevoegde kolom (waarin het belang van een requirement wordt aangegeven) in een requirementlist wordt "Attribuut" genoemd.

Richtlijn 3:
Met een attribuut wordt extra informatie toegevoegd aan een requirement. ZONDER dat het requirement textueel wijzigt.

Richtlijn 3:
Probeer woorden als: "moeten", "mogen", "liefst" en "dienen" te vermijden bij het opstellen van een requirement. Neem deze begrippen op als attribuut.

Richtlijn 3:
Gebruik geen voorbeelden in een requirement. Maar zet voorbeelden in een aparte kolom "attribuut".

Richtlijn 3:
In een requirement mag je ook uitleg geven op de betekenis van een woord als het niet duidelijk is.

Richtlijn 3:
Je mag bij het formuleren van een requirement GEEN motivatie erbij zetten.

Richtlijn 4:
Het koffiezetapparaat heeft een thermoskan. Dit beschrijft de behoefte.

Richtlijn 4:
Met de vraag "Waarom moet het apparaat deze oplossing hebben" krijg je de werkelijke behoefte van een requirement.

Richtlijn 4:
Het probleemdomein richt zich op de behoefte en het oplossingsdomein richt zich op de oplossing.

Richtlijn 4:
De "waarmee" vraag geeft de oplossing voor de behoefte.

Richtlijn 4:
De "Waarom" vraag geeft de behoefte achter de oplossing.

Richtlijn 4:
Oplossingen in een requirement zijn te herkennen aan het gebruik van zelfstandig naamwoorden. (timer)

Richtlijn 5:
Schrijf bondige zinnen die het liefst meerde behoeftes verwoorden.

Richtlijn 5:
Automaire Requirements: zijn requirements die maar één behoefte verwoorden.

Richtlijn 5:
De volgende requirement is goed: "De kwast kan verf aanbrengen en kan vaker gebruikt worden."

Richtlijn 5:
"Het koffiezetapparaat kan minimaal 12 kopjes koffie zetten." Is goed geschreven.

Richtlijn 5:
Iedere requirement is even belangrijk.

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.

Richtlijn 6:
Identificeer vaagheden met <....>. Zo is duidelijk dat hier getallen of andere eenheden worden toegevoegd.

Richtlijn 6:
De vage begrippen tussen de haken <...> kunnen twee dingen verwoorden. Een kwantificering en één of meerdere substellingen.

Richtlijn 6.
Als je in je requirement een vaagheid(snel) gebruikt. Dan MOET je deze uitwerken.

Richtlijn 6.
Requirements die verwoorden waaraan iets NIET moet voldoen zijn toegestaan. Maar dan moet je wel in de substelling verwoorden wat WEL moet.

Richtlijn 7.
Kwantificeren betekend: uitdrukken in getal en eenheid.

Richtlijn 7.
Een gekwantificeerde vaagheid, is geen onderdeel van een requirement. De kwantificering krijgt daarom ook een unieke aanduiding (eigen nummer).

Richtlijn 7.
Een kwantificering geeft antwoord op de "hoe <vaagheid>".

Richtlijn 7.
Het kwantificeren van een requirement is hetzelfde als het meetbaar maken van een requirement.

Richtlijn 7.
Kwantificeren maakt het requirement specifieker.

Richtlijn 8.
Substelling zijn requirements, die je op hun beurt kunt uitwerken in substellingen en kwantificering.

Richtlijn 8.
Bij het uitwerken van vage termen mag je de oplossing beschrijven.

Richtlijn 9.
Naast "functies" en "kwaliteiten" zijn er ook "regels".

Richtlijn 9.
Functies worden ook wel "functional requirements" genoemd. En kwaliteiten "non- functional requirements".

Richtlijn 10.
Houd bij een requirement de woordkeuze beperkt. Gebruik bijvoorbeeld niet telkens iets anders (beker, glas, kopje)

Richtlijn 10.
Een afgesproken beperkte woordenschat heet ook wel: Compromised Language

Richtlijn 11.
Glossary = een verklarende woordenlijst.

Richtlijn 12.
Een gezichtspunt is ook een requirement.

Richtlijn 12.
Inventariseer eerst welke gezichtspunten belangrijk zijn, en stel daarna pas de requirements daarbij op.

Richtlijn 12.
De ISO 9126 standaart, is een overzicht van goed opgestelde requirements.

Richtlijn 12.
COPAFIJTH is een overzicht van gezichtspunten.

Richtlijn 13.
Met Proza maak je duidelijk: in welke situatie de lezer zich het beste kan inleven.

Richtlijn 13.
Proza verwoord helder de context waar de requirements betrekking op hebben.

Richtlijn 13.
De inleidende text (Proza) mag voorbeelden van requirements bevatten.

Richtlijn 14.
De combinatie van belang en urgentie bepaald de prioriteit van een requirement.