Hoofdstuk 15 – Specificatietechnieken
Formuleren
Alle specificaties moeten voor alle belanghebbenden goed leesbaar en
voor e1én uitleg vatbaar zijn.
Juiste detailnivaeu kiezen
Het is de kunst om kort en bondig de essentie over te brengen. Analist
moet aan ene kant veel aandacht besteden aan het eenduidig en goed
leesbaar vastleggen en aan de andere kant beseffen dat de perfecte
specificaties niet bestaan noodzakelijk om niet door te slaan naar
perfectionisme. Ze zullen nooit 100 procent zijn. Detailniveau is afhankelijk
van gekozen ontwikkelproces en participatie van gebruikers. Het is een
goede werkwijze om door te gaan met toevoegen van details totdat de
ontwikkelaars en testers tevreden zijn.
Voldoende informatie geven:
Informatie gaat wel eens mis in de volgende gevallen:
- Bij grenswaarden
Vaak onduidelijk bij welke groep een waarde hoort die op de grens
van twee groepen ligt. Om misverstanden te voorkomen moet
analist expliciet aangeven tot welke groep de grenswaarden
behoren. Bij staffel kan een tabel worden gebruikt.
- Bij een systeemactie
Bij een actie is het van belang om te weten wat de aanleiding
daarvan is. Als dit niet eenduidig is, moet het expliciet worden
gespecificeerd.
- Bij een controle
Dient duidelijk te zijn wat gecontroleerd moet worden en wanneer dit
slaagt en welke condities. Voor alle mogelijke uitkomsten moet een
vervolgactie duidelijk zijn.
- Bij een conditie
Uit specificaties moet duidelijk blijken wat het systeem moet doen
als wel en als niet aan de conditie voldaan wordt.
Onduidelijke formuleringen vermijden:
Hoe duidelijker specificaties zijn, hoe beter. Volgende formuleringen
vermijden:
- Dubbele ontkenning
Zinnen herformuleren en prettig laten lezen.
- Meervoudige conditie waarin zowel ‘en’ als ‘of’ voorkomt
Geeft vaak aanleiding tot interpretatieverschillen. Beste opgesplitst
worden in afzonderlijke requirements.
- Meervoudige conditie met geneste ‘als dan’
Is moeilijk leesbaar. ‘als dan’ kan beter vervangen worden door een
opsomming. Hiervoor kan beter een beslissingstabel voor worden
gebruikt met alle mogelijkheden.
- Negatieve requirements
Formuleren
Alle specificaties moeten voor alle belanghebbenden goed leesbaar en
voor e1én uitleg vatbaar zijn.
Juiste detailnivaeu kiezen
Het is de kunst om kort en bondig de essentie over te brengen. Analist
moet aan ene kant veel aandacht besteden aan het eenduidig en goed
leesbaar vastleggen en aan de andere kant beseffen dat de perfecte
specificaties niet bestaan noodzakelijk om niet door te slaan naar
perfectionisme. Ze zullen nooit 100 procent zijn. Detailniveau is afhankelijk
van gekozen ontwikkelproces en participatie van gebruikers. Het is een
goede werkwijze om door te gaan met toevoegen van details totdat de
ontwikkelaars en testers tevreden zijn.
Voldoende informatie geven:
Informatie gaat wel eens mis in de volgende gevallen:
- Bij grenswaarden
Vaak onduidelijk bij welke groep een waarde hoort die op de grens
van twee groepen ligt. Om misverstanden te voorkomen moet
analist expliciet aangeven tot welke groep de grenswaarden
behoren. Bij staffel kan een tabel worden gebruikt.
- Bij een systeemactie
Bij een actie is het van belang om te weten wat de aanleiding
daarvan is. Als dit niet eenduidig is, moet het expliciet worden
gespecificeerd.
- Bij een controle
Dient duidelijk te zijn wat gecontroleerd moet worden en wanneer dit
slaagt en welke condities. Voor alle mogelijke uitkomsten moet een
vervolgactie duidelijk zijn.
- Bij een conditie
Uit specificaties moet duidelijk blijken wat het systeem moet doen
als wel en als niet aan de conditie voldaan wordt.
Onduidelijke formuleringen vermijden:
Hoe duidelijker specificaties zijn, hoe beter. Volgende formuleringen
vermijden:
- Dubbele ontkenning
Zinnen herformuleren en prettig laten lezen.
- Meervoudige conditie waarin zowel ‘en’ als ‘of’ voorkomt
Geeft vaak aanleiding tot interpretatieverschillen. Beste opgesplitst
worden in afzonderlijke requirements.
- Meervoudige conditie met geneste ‘als dan’
Is moeilijk leesbaar. ‘als dan’ kan beter vervangen worden door een
opsomming. Hiervoor kan beter een beslissingstabel voor worden
gebruikt met alle mogelijkheden.
- Negatieve requirements
