beschreven theorie. Aangezien deze theorie niet overzichtelijk en daarmee moeilijk te
vertalen is naar een model, is de beschreven theorie samengevat in de vorm van kernpunten.
In tabel 5 zijn deze kernpunten genoemd, die per fase zijn uitgewerkt.
tabel 5 – Kernpunten theoretisch functioneel specificatieproces
Fase Karakteristieken
0. Alge
meen
0.1. Splitsing proces in probleem- en oplossingsdomein;
0.2. Het specificatieproces is een continue iteratie tussen de eisenspecificatie en het ontwerp, waarbij het abstractieniveau afneemt;
0.3. Balans vinden tussen scheiding van domeinen en nauwe (iteratieve) interactie; 0.4. Het RE proces is afhankelijk van drie dimensies: (1) specificatie, representatie en
overeenstemming;
0.5. Problemen in het RE proces komen voort uit de bovengenoemde dimensies; 0.6. Het proces dient te zijn gebaseerd op het V-model;
0.7. Het proces van identificatie t/m ontwerp bestaat uit vier fasen: (1) identificatiefase, (2) specificatiefase, (3) ontwerp en (4) verificatie & validatie;
0.8. De eisen in het proces zijn in te delen in drie categorieën: (1) functionele eisen, (2) niet-functionele eisen en (3) randvoorwaarden.
1. I
dentif
ica
tief
ase
1.1. Het doel is te komen tot antwoord op de vraag: welk effect op de omgeving is gewenst? 1.2. Behoort tot het probleemdomein;
1.3. Eisen en wensen (potentiële eisen) kunnen niet bij de opdrachtgever worden “gehaald”, maar moeten in interactie met de opdrachtnemer worden geïdentificeerd;
1.4. Niet uitsluitend dienen potentiële eisen te worden geïdentificeerd, maar ook dient begrip te worden verkregen van het applicatiedomein, het probleem en de organisatie (van de opdrachtgevende partij);
1.5. Stakeholders dienen door opdrachtgever en opdrachtnemer/ontwerper te worden geïdentificeerd op basis van de attributen van invloed, legitimiteit en urgentie, die in samenhang een 8-tal typologieën mogelijk maakt;
1.6. De stakeholders variëren qua aantal in het proces in de tijd bezien, maar zijn zelf ook qua inhoud dynamisch door toevoeging of vermindering van een of meerdere attributen;
1.7. Voordat de potentiële eisen kunnen worden omgezet in formele eisen, dient er overeenstemming te worden bereikt tussen de actoren.
2. Specif
icat
iefa
se
2.1. Het doel is te komen tot een antwoord op de vraag: wat moet het gedrag van het systeem zijn op de grens met de omgeving om het gewenste effect op de omgeving te bereiken?
2.2. Behoort in het proces tot het functioneel oplossingsdomein, in termen van fysieke oplossingen behorend tot het probleemdomein;
2.3. Functionele eisen beschrijven wat het systeem moet doen (reden van bestaan);
2.4. Functionele eisen kunnen worden gecategoriseerd in twee groepen: (1) basis functies en additionele functies;
2.5. Niet-functionele eisen zijn die eisen die de eigenschappen van het systeem specificeert; 2.6. Niet-functionele eisen bestaan uit acht groepen: (1) uiterlijk en gevoelseisen, (2)
bruikbaarheidseisen, (3) prestatie-eisen, (4) operationele eisen, (5) onderhoudbaarheid- en vervangbaarheidseisen, (6) veiligheidseisen, (7) culturele en politieke eisen en (8) wettelijke eisen;
2.7. Randvoorwaarden zijn de factoren die toepassing hebben op het gehele product. Het gaat niet zozeer op eisen waar de procesactoren invloed op hebben, maar om opgelegde eisen vanuit de omgeving.
2.8. Fit criteria dienen te worden vastgesteld om validatie van functionele eisen mogelijk te maken;
2.9. Er dienen eisen aan de eisen te worden gesteld, die waarop de eisen moeten worden gecontroleerd;
Fase Karakteristieken 3. O ntw er pf as e
3.1. Het doel is te komen tot antwoord op de vraag: wat moet het interne gedrag en de structuur van het systeem zijn, dat leidt tot het gewenste gedrag op de grens met de omgeving?
3.2. Behoort tot het oplossingsdomein;
3.3. Dient gebaseerd te zijn op een drietal principes: (1) simpliciteit, (2) onafhankelijkheid en (3) modulariteit;
3.4. Praktisch leidt dit tot vier deelfasen: (1) variantenstudie, (2) relatiefase, (3) modularisatiefase en (4) simplificatiefase;
3.5. Op basis van de support en ongewenste functies die functievervullers met zich meebrengen, kan worden gekomen tot een expliciete ontwerpkeuze, waarbij moet worden gestreefd naar minimalisatie van support functies en eliminatie van ongewenste functies;
3.6. Moet worden gestreefd naar zo lang mogelijk oplossingsvrij en innovatief te denken, waarbij de keuze voor een functionele architectuur voort moet vloeien uit het proces; 3.7. Ontwerp behoeft niet uitsluitend creatief te zijn, maar kan expliciet worden gemaakt; 3.8. Ontwerp is te beoordelen op waardecreatie voor de klant in de specificatiefase
gemaakte splitsing van basis en additionele functies.
4. V eri fi cati e- en v alid atiefase
4.1. Verificatie is het controleren of de systeem- en ontwerpspecificatie voldoen; 4.2. Verificatie vindt plaats binnen een niveau (confrontatie van systeem- aan
ontwerpspecificatie) en tussen niveaus voor onderlinge controle;
4.3. Validatie is het vaststellen dat het systeem die dingen doet die het systeem zou moeten doen;
4.4. Validatie is mogelijk door gebruik van fit criteria als referentiekader, ter beoordeling aan de procesactoren (opdrachtgever, opdrachtnemer en stakeholders);
4.5. Kwaliteit van functionele eisen of vertaling daarvan in een ontwerp is niet aan waardevermindering onderhevig;
4.6. Decompositie is het afleiden van eisen uit het gemaakte ontwerp dat input is voor de specificatiefase op een lager niveau;
4.7. Interface-eisen als eisen tussen subsystemen onderling, zijn cruciaal voor de afstemming onderling