Systems engineering : expliciet functioneel specificeren en ontwerpen: een haalbare wens?

Colofon

Studie

Universiteit Twente

Faculteit Construerende Technische Wetenschappen Afstudeerrichting Bouwprocesmanagement

Begeleiders:

ir. K.T. Veenvliet

prof. dr. ir. J.I.M. Halman

Opdrachtgever

Movares

Divisie Grote Projecten, vakgroep Projectmanagement Begeleider:

ir. J.P.M. Oorsprong, senior projectmanager

Auteur

ing. E. C. Uil

Telefoon: 06 44 162 904 E-mailadres: e.c.uil@planet.nl

Gecontroleerd

ir. J.P.M. Oorsprong

Vrijgegeven

drs. ir. A.J.J.M. Schillemans

Woord vooraf

Een korte, maar intensieve periode studeren aan de Universiteit Twente rond ik binnenkort succesvol af. Het hebben van een master Civil Engineering & Management, als aanvulling op mijn HTS civiele techniek, resulteert hierdoor in de waardevolle combinatie van wetenschappelijke niveau met praktische kennis. Het is de investering qua opgedane kennis, algemene ontwikkeling en ervaring dan ook meer dan waard!

Met trots mag ik de afstudeerrapportage die voor u ligt aan u presenteren. De ontwikkelingen op het gebied van systems en requirements engineering zijn aangegrepen, om in opdracht van Movares expliciet invulling te geven aan het functioneel specificatieproces. De persoonlijke uitdaging om op dit gebied expert te worden, werd gevoed door de relatieve onbekendheid bij ProRail met dit kennisdomein. Aangezien ProRail een belangrijke opdrachtgevende partij is, is de relevantie van het onderzoek niet uitsluitend binnen maar ook buiten de organisatie van Movares gelegen.

Naast een groot enthousiasme voor dit onderwerp, was er de drive om obstakels niet uit de weg te gaan. Door deze als uitdaging te zien en aan te grijpen om te komen tot nieuwe inzichten en ontwikkelingen, hebben mede de kwaliteit van het eindproduct bepaald.

In dit voorwoord zou ik graag de mensen willen bedanken, die mij geholpen hebben om tot dit resultaat te kunnen komen. Allereerst wil ik graag mijn begeleiders de heer J. Oorsprong namens Movares en de heer K. Veenvliet en de heer J. Halman namens de Universiteit Twente bedanken voor hun inbreng van expertise, feedback en sturing gedurende het project. De heer T. Schillemans zou ik graag willen bedanken voor de mogelijkheid en middelen die hij mij heeft geboden om te kunnen afstuderen binnen Movares. De deskundigen binnen Movares en ProRail wil ik bedanken voor hun bereidheid voor het afnemen van de interviews.

De medewerkers van T-Xchange zou ik graag willen bedanken voor de mogelijkheid die is geboden voor het houden van de expert meeting. Uiteraard ook dank voor alle deelnemers aan de expert meeting.

Mijn vrienden, bedankt voor de gezelligheid naast het afstuderen. Speciale dank voor mijn familie die mij door alle perioden heen hebben gesteund en altijd voor mij klaar staan. Tot slot wil ik Willemien bedanken voor haar steun, feedback en luisterend oor gedurende mijn gehele afstuderen.

Ondanks het feit dat het onderwerp complexe materie is, hoop ik dat u met plezier en enthousiasme het rapport zult lezen. Wellicht komt u tot nieuwe inzichten die u praktische toepassing kan geven.

Erwin Uil

Lelystad, september 2006

Samenvatting

Inhoudsopgave

1 Inleiding... 8

2 Onderzoeksontwerp... 9

2.1 Inleiding... 9

2.2 Movares – de organisatie... 9

2.3 Probleemidentificatie ... 9

2.3.1 Aanleiding binnen Movares... 9

2.3.2 Kennisbelang... 10

2.3.3 Wetenschappelijke aanleiding ... 10

2.4 Probleemdomeinen - onderzoekscontext... 12

2.4.1 Opbouw... 12

2.4.2 Requirements engineering ... 12

2.5 Conceptueel ontwerp ... 14

2.5.1 Probleemstelling ... 14

2.5.2 Doelstelling ... 14

2.5.3 Vraagstelling ... 14

2.6 Onderzoekstechnisch ontwerp... 15

2.6.1 Onderzoeksmodel... 15

2.6.2 Onderzoeksstrategieën ... 16

3 Theoretisch functioneel specificatieproces ... 17

3.1 Inleiding... 17

3.2 Het specificatieproces – Eisen in het probleem- en oplossingsdomein ... 17

3.3 De drie dimensies van het RE proces ... 19

3.4 Representaties van het specificatieproces ... 22

3.5 Fasering van het specificatieproces... 24

3.6 Fase 1: Identificatiefase – Van wensen naar potentiële eisen... 27

3.6.1 Identificeren ... 27

3.6.2 Overeenstemming ... 30

3.6.3 Identificatie van stakeholders ... 31

3.7 Fase 2: Specificatiefase – Van potentiële naar formele eisen ... 34

3.7.1 Functionele eisen ... 34

3.7.2 Niet-functionele eisen ... 36

3.7.3 Randvoorwaarden ... 37

3.7.4 Fit criteria ... 37

3.7.5 Eisen aan eisen ... 38

3.8 Fase 3: Ontwerpfase – Van formele eisen naar ontwerp ... 40

3.8.1 Ontwerpprincipes ... 40

3.8.2 Ontwerparchitectuur ... 42

3.9 Fase 4: Verificatie & validatiefase – Van ontwerp naar vervulling van wensen... 44

3.9.1 Verificatie ... 44

3.9.2 Validatie ... 44

3.9.3 Kwaliteit van functionele eisen ... 45

3.9.4 Decompositie ... 46

3.10 Modellering ... 46

3.11 Deelconclusie ... 50

4 Huidig functioneel specificatieproces... 52

4.1 Inleiding... 52

4.2 De casestudy voor kwalitatief onderzoek... 52

4.2.1 Theorie... 52

4.2.2 Operationalisatie... 54

4.3 Casestudy – Hanzelijn ... 57

4.3.1 Projectinformatie ... 57

4.3.2 Interviews... 57

4.3.3 Documentenstudie ... 58

4.3.4 Analyse... 60

4.4 Casestudy – HSL-Portugal ... 62

4.4.1 Projectinformatie ... 62

4.4.2 Interviews... 62

4.4.3 Documentenstudie ... 63

4.4.4 Analyse... 63

4.5 Eisen en verwachtingen ProRail functioneel specificatieproces ... 65

4.5.1 Inleiding ... 65

4.5.2 Interviews ProRail... 65

4.5.3 Documentenstudie ... 65

4.5.4 Analyse... 67

4.6 Relateren data ... 69

4.7 Deelconclusie ... 71

5 Verbetervoorstel functioneel specificatieproces ... 75

5.1 Inleiding... 75

5.2 Verbeterpunten theoretisch functioneel specificatieproces... 75

5.2.1 Fase 1: Identificatiefase... 75

5.2.2 Fase 2: Specificatiefase... 75

5.2.3 Fase 3: Ontwerpfase ... 76

5.3 Verbeterpunten huidig functioneel specificatieproces... 76

5.3.1 Algemeen... 76

5.3.2 Fase 1: Identificatiefase... 77

5.3.3 Fase 2: Specificatiefase... 77

5.3.4 Fase 3: Ontwerpfase ... 78

5.3.5 Fase 4: Verificatie- en validatiefase ... 78

5.4 Deelconclusie ... 80

6 Haalbaarheid verbetervoorstel – Expert Meeting ... 82

6.1 Inleiding... 82

6.2 T-Xchange... 82

6.3 Ontwerp Expert Meeting ... 83

6.4 Resultaten en analyse expert meeting... 86

6.4.1 Haalbaarheid functioneel specificatieproces binnen Movares ... 86

6.4.2 Barrières implementatie functioneel specificatieproces... 87

6.5 Deelconclusie ... 88

7 Conclusies en aanbevelingen ... 89

7.1 Conclusies ... 89

8 Begrippenlijst... 92

9 Referenties ... 93

9.1 Literatuur ... 93

9.2 Publicaties/ rapporten/ presentaties... 95

9.3 Websites ... 95

9.4 Workshops... 95

Bijlage 1 Onderzoeksontwerp... 96

§ 2.2 – Organogram organisatie Movares... 96

§ 2.4 – Probleemdomeinen – Onderzoekscontext ... 97

Bijlage 2 Theoretisch functioneel specificatieproces ... 104

§ 3.7.5 – Formulering van eisen ... 104

§ 3.8.2 – Ontwerparchitectuur... 106

Bijlage 3 Huidig functioneel specificatieproces ... 107

§ 4.3.1 – Tracékaart Hanzelijn ... 107

§ 4.3.2 & 4.4.2 – Interviewschema praktijkstudie... 108

§ 4.3.2 – Uitwerkingen interviews casestudy Hanzelijn... 109

§ 4.4.2 – Uitwerkingen interviews casestudy HSL-Portugal... 114

§ 4.5.2 – Interviewschema ProRail functioneel specificeren ... 117

§ 4.5.2 – Uitwerkingen interviews ProRail... 118

Bijlage 4 Haalbaarheid verbetervoorstel – Expert Meeting ... 122

§ 6.3 – Ontwerp Expert Meeting ... 122

§ 6.4 – Resultaten en analyse expert meeting ... 124

1 ^Inleiding

De huidige bouwsector is een dynamische markt vol veranderingen. Een belangrijke trend in Nederland is het overlaten van taken in het voortbrengingsproces van infrastructurele projecten door de overheid aan de markt (ONRI, 2005). Dit zogenoemde terugtrekken van de overheid, waaronder ProRail als belangrijke opdrachtgever op het gebied van railinfrastructuur, creëert ruimte die als uitdaging moet worden gezien voor ingenieursbureaus. Ruimte en stimulans voor eigen inbreng van opdrachtnemers zal de doelmatigheid en efficiëntie van het project ten goede komen (Luiten et al., 2005). Ook de verschuiving van denken in termen van de laagste prijs naar een beoordeling op meest economische waarde en levenscyclusbenadering biedt volop kansen (ONRI, 2005; Luiten et al., 2005).

Echter een brede scope maakt een project complex en daarmee moeilijker beheersbaar. Veel eigen inbreng, met de openheid van de vraagstelling die daarvoor nodig is, maken het project onzekerder en complexer voor de opdrachtgever. Hierdoor wordt, vanuit het perspectief van de opdrachtgever, het project minder makkelijk beheersbaar (Luiten et al., 2005).

Om dit te compenseren, willen opdrachtgevende partijen graag inzicht in de wijze waarop tot het product wordt gekomen. In toenemende mate wordt daarom (door de opdrachtgevende partijen) verlangd te werken volgens de werkwijze van SE. In o.a. de vliegtuigindustrie, Amerikaanse Defensie (DoD), telecommunicatie-industrie, ruimtevaartindustrie en software-industrie is deze werkwijze efficiënt en effectief gebleken (Blanchard, 1998; Martin, 2000; DoD, 2001). De eis voor opdrachtnemende partijen om te werken volgens SE, betekent dat zij kennis moeten ontwikkelen om deze projecten te kunnen uitvoeren.

De efficiëntie en effectiviteit die SE kan opleveren, hangt voor een groot deel af van de eerste fase van het voortbrengingsproces, dat het kennisdomein van requirements engineering (RE) omvat. Essentieel onderdeel van dit proces is het helder krijgen van de eisen, dat in de praktijk veel problemen op blijkt te leveren. De eisen zijn de sleutel tot het succes of falen van een (technisch) project (Young, 2004).

Movares wil als ingenieurs- en adviesbureau inspelen op de markt, door expertise te ontwikkelen op het gebied van SE. Hierdoor is betere aansluiting bij de wensen van de klant mogelijk, en kan door die kennis competitief voordeel worden behaald door pro-actief in te spelen op de ontwikkelingen in de markt. Dit onderzoek zal op deze behoefte inspelen, door invulling te geven aan het expliciet functioneel specificeren en ontwerpen in de context van SE.

Het rapport is als volgt opgebouwd. In hoofdstuk 2 zal het onderzoeksontwerp worden beschreven waar de probleemidentificatie, de onderzoekscontext en het ontwerp van het onderzoek centraal zullen staan. Vervolgens zal expliciet invulling worden gegeven aan de titel van het onderzoek, door hoofdstuk 3 t/m 6. In hoofdstuk 3 zal een theoretische beschrijving van het functioneel specificatieproces worden gegeven, dat zal resulteren in een procesbeschrijving. In hoofdstuk 4 zal aandacht worden besteed aan de empirie, waar zal worden gekomen tot constateringen en knelpunten gerelateerd aan het functioneel specificatieproces. Deze laatste twee hoofdstukken zullen wederzijds aan elkaar worden geconfronteerd, dat resulteert in een verbetervoorstel voor het functioneel specificatieproces in hoofdstuk 5. Tot slot is middels een expert meeting onderzocht of het verbetervoorstel ook praktisch en succesvol in de praktijk implementeerbaar is. In hoofdstuk 6 zal dit worden beschreven.

2 Onderzoeksontwerp

2.1 I

Dit hoofdstuk heeft tot doel het probleem te identificeren en te komen tot een doelstelling en ontwerp voor het onderzoek. Hiertoe zal allereerst in paragraaf 2.3 het probleem worden geïdentificeerd, dat zowel vanuit het perspectief van de organisatie van Movares alsmede vanuit het perspectief van de wetenschap zal worden belicht. Vervolgens zal door bestudering en inkadering van probleemdomeinen de onderzoekscontext worden vastgesteld. Dit vormt tevens de scope van het onderzoek (zie paragraaf 2.4). Op basis hiervan is het mogelijk een (gericht) conceptueel en onderzoekstechnisch ontwerp voor het onderzoek te maken (zie paragrafen 2.5 en 2.6).

2.2 M

–

Movares heeft als ingenieurs- en adviesbureau veel kennis en ervaring op het gebied van railinfrastructuur. Echter door de veranderende markt, maken nu ook projecten op het gebied van vervoerssystemen deel uit van het werk. Deze verschuiving van de aard van de projecten, in combinatie met het uitvoeren van projecten in het buitenland, was dan ook de reden van de recente naamswijziging van ‘Holland Railconsult’ naar ‘Movares’. Enkele voorbeelden van grote projecten zijn de Hogesnelheidslijn-Zuid, de Betuweroute en het project VleuGel met onder meer de aanleg van twintig light-railstations.

Het afstudeeronderzoek zal worden uitgevoerd binnen de groep ‘Leiding & Staf’, die valt onder de vakgroep projectmanagement onderdeel uitmakend van de divisie Grote Projecten (zie figuur 32 en figuur 33, Bijlage 1). Omdat binnen de divisie Grote Projecten zowel vakgroepen als projectbureaus bestaan, wordt deze gekarakteriseerd als een matrixorganisatie.

2.3 P

2.3.1

De in de inleiding beschreven dynamiek van de markt, is op dit moment sterk aanwezig binnen de organisatie van Movares. Dit komt doordat ProRail als voornaamste opdrachtgever in de vraagspecificatie een werkwijze volgens SE voorschrijft. Voldoen aan deze vraag is dus noodzakelijk voor de acquisitie van projecten, aan te sluiten bij de wensen van de klant en competitief te kunnen opereren op de markt.

De implementatie van een werkwijze volgens SE vraagt de nodige expertise en een verandering in de huidige werkwijze. Momenteel worden de projecten HSL-Portugal en de Hanzelijn als eerste projecten binnen Movares uitgevoerd volgens de werkwijze van SE.

Gedurende de uitvoering van deze projecten is gebleken dat er behoefte is voor ontwikkeling van de kennisdomeinen van SE en RE. Hierbij speelt met name de behoefte aan transparantie ten aanzien van gemaakte ontwerpkeuzes en de wijze waarop daartoe is gekomen een grote rol. Echter is hier nog onvoldoende kennis van om dit op consistente wijze uit te voeren. Er is duidelijk behoefte aan overzicht en een leidraad voor het specificeren van eisen binnen de organisatie. Dit is met name van belang omdat de opdrachtgever bij een werkwijze volgens SE verlangt om inzichtelijk te maken hoe gekomen

is tot het eindproduct. Dit is o.a. te verklaren door het feit dat de opdrachtgever in financiële zin verantwoording over de uitgave van belastinggeld.

De door ProRail aangeboden projecten worden veelal ‘opgeknipt’ in deelcontracten en

aangeboden aan verschillende marktpartijen. De voornaamste reden hiervan ligt in het feit

dat er verschillende expertises betrokken zijn bij de uitvoering van een

railinfrastructuurproject. Denk maar aan de expertises voor de bouw van een viaduct en de

aanleg van een beveiligingssysteem voor het spoor. Daarnaast spelen planningstechnische

aspecten en spreiding van risico’s mee als reden. Door het ‘opknippen’ ontstaan interfaces

die voor problemen zorgen in de communicatie, afstemming en uitvoering van het project. Dit levert een spanningsveld op tussen enerzijds het technisch beheersbaar maken van het project en anderzijds de beheersbaarheid omtrent de communicatie door het aantal interfaces.

Verplaatsend in de rol van Movares, die opereert als sub-contractor, is het heel lastig om met de generiek opgestelde eisen, die toepassing hebben op verschillende contracten, vast te stellen aan welke eisen het subsysteem moet worden voldaan. We spreken dan nog niet eens van kwalificering van de (gebruikers)eisen in relatie tot het gerealiseerde object.

Naast behoefte voor verbetering van het specificatieproces volgens SE, zijn er ook barrières binnen de organisatie voor algehele implementatie van SE. Dit komt met name door de onbekendheid met het domein van SE, al is dit wel sterk in ontwikkeling.

Concluderend kan worden gesteld dat de eis die de

opdrachtgever stelt voor een werkwijze volgens SE, vraagt om het oplossen van de knelpunten en het ontwikkelen van kennis op het gebied van RE, in de context van SE, met als doel een werkwijze te ontwikkelen die transparantie binnen het functioneel specificatieproces mogelijk maakt.

2.3.2

Zoals in de vorige paragraaf al is aangegeven, is ontwikkeling van kennis een voorwaarde om te komen tot transparantie in het proces voor het specificeren van eisen. Inzicht in dit proces kan voordelen opleveren in de vorm van kwaliteit, structuur en als communicatiemiddel dat bruikbaar is voor toekomstige projecten. De vakgroep Projectmanagement, waar het onderzoek zal worden uitgevoerd, kan hier voordeel mee behalen. Ook andere divisies binnen Movares zouden hiermee hun voordeel kunnen doen.

Uiteraard moet de focus niet uitsluitend binnen de organisatie liggen. De genoemde voordelen kunnen namelijk ook in de vorm van adviesdiensten worden gedeeld met andere partijen, waaronder opdrachtgevers. Daarnaast kan, wanneer het proces om te komen tot eisen binnen Movares helder is, dit worden gecommuniceerd met ProRail. Wanneer inzicht in dit proces wordt verkregen, kan de communicatie tussen opdrachtgever-opdrachtnemer worden verbeterd. Concreet kan dan worden aangetoond op welke wijze Movares omgaat met het specificeren van eisen en wat omgekeerd door de opdrachtgever in de vorm van input wordt verlangd. Tevens is er bij INCOSE een certificering op het gebied van SE in ontwikkeling. De producten van dit onderzoek zouden dan bijvoorbeeld kunnen worden gebruikt om deze certificering in aanmerking te komen.

De noodzaak voor de uitvoering van dit onderzoek is niet alleen gelegen in een behoefte vanuit de organisatie. Ook binnen de wetenschap wordt er geworsteld met problemen die spelen binnen het domein van RE, zo zal blijken in de volgende paragraaf.

2.3.3

De voortbrengingsprocessen om te komen tot een product verschillen van sector tot sector.

Kijkend naar de bouwsector zou je door de lage toetredingsdrempel verwachten dat het voortbrengingsproces weinig complex zal zijn. Echter het tegendeel is waar. De bouw kenmerkt zich namelijk o.a. door: projectgewijze productie, uniciteit, locatiegebondenheid, tijdelijke coalities, technocratie en veelal een scheiding tussen ontwerp en uitvoering (Boes et al., 2004). Door projectgewijze productie zijn er geen schaalvoordelen te behalen; elk proces is uniek. Daar komt bij dat door de vele bij het voortbrengingsproces betrokken actoren, de

L Praktijk

ProRail specificeert een tijd van 30 minuten voor een trein om het traject van Lelystad naar Zwolle van 50 kilometer af te leggen. Movares heeft als subcontractor de taak de aansluitingen op het bestaande spoor en de tussenliggende stations Dronten en Kampen uit te voeren. Het is echter door de gestelde tijd van 30 minuten, niet duidelijk waaraan het deelcontract moet voldoen. Wanneer Movares bijvoorbeeld een kostenbesparend ontwerp voorstelt dat geschikt is voor lage snelheden, dan zal dit moeten worden gecompenseerd op de andere delen. Echter gelden hiervoor wel randvoorwaarden zoals een maximum snelheid van 200 kilometer per uur. Hoe kan dit nu op elkaar aansluiten?

van aard, met velerlei interfaces tussen de projectonderdelen. Dit maakt het project dynamisch complex (Brunton & Tarling, 2003).

De principes van SE kunnen, kijkend naar deze karakteristieken, van belangrijke betekenis zijn voor de railinfrasector. Met name kan er voordeel worden behaald op de volgende punten (Brunton & Tarling, 2003): (1) ‘scope of control’ door eisen, (2) management en interfacemanagement en (3) kennis van al de projecteisen. Hieruit blijkt dat eisen in het ontwikkelproces een belangrijke rol spelen. Maar waarom zijn deze zo essentieel?

Het succes van het specificeren van eisen in projecten, hangt grotendeels af van de ‘match’

tussen de eisen van de klant en de product- en proceskennis van het bedrijf. Ratchev et al.

(2003) zien het dan ook als de “sleutelfase” van het gehele SE proces. Een kritisch punt voor het ontbreken van de ‘match’, is het onvoldoende begrijpen en verkeerd transformeren van de gebruikerseisen in producteisen vanuit de opdrachtnemer. Onvoldoende inzicht in het functioneel specificatieproces door inaccurate aannames die zijn gemaakt in de initiatie- en analysefase van de gebruikerseisen kunnen significante consequenties hebben voor het ontwerp en de realisatie van het product, kijkend naar kwaliteit, tijd en kosten (Ratchev et al., 2003). Leinonen (2001) vult hieraan toe: (1) het ontbreken van een systematische benadering, (2) ontbreken van domeinkennis en (3) omgang met veranderende eisen. Deze identificatie sluit aan bij de geïdentificeerde problemen binnen de organisatie van Movares, zie paragraaf 2.3.1.

Eisen zijn belangrijk omdat zij de basis vormen voor alle ontwikkelingen voor het daaropvolgende werk (Young, 2004). Wanneer eenmaal de eisen zijn vastgesteld, wordt verder gegaan met de daadwerkelijke ontwikkeling van het object, testen en operationaliseren van het systeem. De tendens is dat maar al te vaak na acquisitie meteen het

“echte” werk wordt begonnen. Dit wordt veelal gedaan vanuit de intentie dat dit zichtbaar resultaat en dus progressie in de resultaten oplevert (Young, 2004). Ook stakeholders zien het proces van het specificeren van eisen vaak als een onnodige (tijds)investering (Leinonen, 2001).

Dat dit echter geen onnodige tijdsinvestering is, blijkt uit het feit dat de opgestelde eisen veelal significant verschillen van de werkelijke eisen (Young, 2004). De opgestelde eisen zijn deze die door de klant zijn verstrekt aan het begin van de ontwikkeling van het systeem. De werkelijke eisen daarentegen zijn deze de gereflecteerde en geverifieerde behoeften van de gebruikers. Miscommunicatie van eisen leidt tot een verspilling van tijd, moeite en geld (Young, 2004). Met name de kosten die gemoeid zijn met het repareren van eisenfouten zijn het meest kostbaar in het productiestadium; dit in tegenstelling tot wijzigingen die worden gemaakt in het ontwikkelstadium (Katasonov & Sakkinen, 2006; Martin, 2000).

In de softwarebranche is onderzoek gedaan naar de impact die slecht geformuleerde eisen hebben. Hieruit blijkt dat eisen-, specificatie- en ontwerpfouten een substantieel aandeel van 64% hebben, in tegenstelling tot productfouten van 36% (Kotonya & Sommerville, 1996).

NASA heeft dit concreet vertaald naar kosten. Hieruit blijkt dat wanneer het gemiddelde van 2 a 3% van de projectkosten worden geïnvesteerd in het specificatieproces van eisen, de kostenoverschrijding naar schatting 80 tot 200% zal zijn. Dit in tegenstelling tot een investering van 8 tot 14% dat tot een overschrijding van 0 tot 50% zal leiden (Young, 2004).

Uiteraard is de intentie om niet tot kostenoverschrijding te komen, maar dit illustreert de noodzaak tot investering in het functioneel specificatieproces.

Naast het niet of onvoldoende aansluiten bij de gebruikerseisen, zijn er nog eisen die in het

begin van de ontwikkeling van het systeem nog niet bekend waren die voort zijn gekomen

uit nieuwe capaciteiten van het systeem. Deze eisen dienen dus te worden geïmplementeerd

binnen de bestaande eisen. Het identificeren van de werkelijke eisen vereist een interactief

en iteratief proces voor de specificatie van eisen, ondersteund door effectieve processen,

mechanismen, methoden, technieken en tools (Young, 2004).

2.4 P

-

2.4.1

In de vorige paragraaf is het ‘waarom’ van het onderzoek beschreven. Als een stap verder wordt gegaan, dient er meer duidelijkheid te worden verkregen over de context waarin het onderzoek zal worden uitgevoerd. Dit kan worden beschouwd in de vorm van probleemdomeinen. Om de probleemdomeinen te identificeren en hiervan kennis te krijgen, is allereerst een literatuurstudie gedaan. Middels deze kennis werd het mogelijk om een generiek probleemdomein in te kaderen, waardoor aansluiting werd verkregen op een specifieker probleemdomein. Door dit proces te herhalen wordt gekomen tot het probleemdomein waarin het daadwerkelijke onderzoek wordt uitgevoerd. De probleemdomeinen tezamen vormen de onderzoekscontext. Inzicht in de gemaakte keuzes vormen daarbij de afbakening van het onderzoek.

Kijkend naar de probleemdomeinen, kunnen er een viertal worden onderscheiden, namelijk:

(1) Systeem benadering, (2) Complexe product systemen (CoPS), (3) Systems engineering en (4) Requirements engineering (zie 2.4.2). De focus van het onderzoek zal liggen op het domein van requirements engineering dat aansluit bij de probleem- identificatie.

In het verdere betoog zal uitsluitend worden ingegaan op het domein van requirements engineering, waarbij wordt verondersteld dat er kennis is van de overige probleemdomeinen.

Een uitwerking van de eerste drie probleemdomeinen met bijbe- horende keuzes, als resultaat van

de literatuurstudie, zijn echter wel terug te vinden (zie Bijlage 1).

2.4.2

Requirements engineering (RE) kan worden omschreven als een gestructureerde set van activiteiten die achtereenvolgens de stappen van afleiden, valideren en behouden van systeemeisen documenteert. Procesactiviteiten bestaan uit eisenidentificatie, eisenanalyse &

overeenstemming en validatie van eisen. (Kotonya & Sommerville, 1998). De eisen, voortkomend uit het RE proces, dienen te worden gemanaged. Dit wordt ook wel Requirements Management (RM) genoemd. Eisen spelen dus een centrale rol in dit geheel, maar wat zijn nu eisen?

In de literatuur zijn hier verschillende opvattingen over. Martin (2000) definieert een eis als volgt: (1) een karakteristiek dat de voltooiing van de verschillende niveaus identificeert, voor het halen van doelen onder de geven condities en (2) een bindende formulering in een document of contract. Kotonya & Sommerville (1998) hanteren de volgende definitie: een uitdrukking van de service of randvoorwaarde van een systeem. Het ministerie van V&W (2005) drukt een eis in de context van functioneel specificeren uit als: in eisen is vastgelegd wat het systeem in de vorm van een functie moet kunnen, waarbij de prestatie de mate van het vervullen van de functie is. Tot slot definieert Young (2004) een eis als: een noodzakelijk attribuut in een systeem, een uitdrukking dat capaciteit, karakteristiek of kwaliteitsfactor van een systeem identificeert om waarde en gebruik voor de klant of gebruiker te creëren.

Voor dit onderzoek is naar aanleiding van deze definities van een eis, gekomen tot een definitie voor het onderzoek, en luidt als volgt:

Een noodzakelijk attribuut in een systeem op verschillende systeemniveaus dat

uitdrukking geeft aan een capaciteit, karakteristiek of kwaliteitsfactor in de vorm van een

Invulling geven aan RE in de praktijk, lijkt ogenschijnlijk weinig implementatieproblemen te kennen. De praktijk schetst echter een ander beeld, zo blijkt uit onderzoek van Standish Group (in Hull et al., 2005; zie figuur 2). Hierin zijn de met stip gemarkeerde punten direct gerelateerd aan (de specificatie van) eisen.

Eisen spelen dus een wezenlijk onderdeel in een project. Echter moeten deze niet los worden gezien, maar in samenhang met het modelleren van een systeem (Hull et al., 2005).

Sommige mensen spreken van het modelleren van eisen; dit is echter onjuist. Het ontwerp van het systeem wordt namelijk gemodelleerd, niet de eisen. Het modelleren helpt de

‘requirements engineer’ het systeem te begrijpen, om vervolgens de eisen van het betreffende (systeem)niveau te decomponeren naar het onderliggende (systeem)niveau. De eisen an sich geven hierin datgene weer wat wordt gevraagd op elk niveau met een toenemende mate van detail (Hull et al., 2005).

Een model als product van het modelleren, is een abstractie van een systeem dat bewust focust op sommige aspecten van het systeem, met uitsluiting van andere aspecten. Onder abstractie in dit geheel moeten worden verstaan het negeren van die details die, doch belangrijk, niet relevant zijn voor het betreffende model. Het voordeel is dat kleinere hoeveelheden informatie kan worden verzameld, verwerkt, gestructureerd en geanalyseerd (Hull et al, 2005). Modellen assisteren de ‘requirements engineer’ in het analyseren van de eisen, waarbij (Hull et al, 2005):

• Communicatie met de klant mogelijk wordt, met vergroting van het wederzijds begrip van het systeem dat wordt ontwikkeld;

• Het systeem kan worden geanalyseerd om er zeker van te zijn dat de gewenste eigenschappen worden opgenomen;

• Vastgesteld wordt op welke wijze aan de eisen wordt voldaan.

Op basis van het voorgaande, in combinatie met de in paragraaf 2.3.1 beschreven aanleiding, zal het doel zijn om een procesmodel voor de specificatie van eisen te ontwikkelen.

Specifieker naar dit RE proces kijkend, kan worden gesteld dat deze wordt gekenmerkt door een drietal categorieën van eisen: (1) functionele eisen, (2) niet-functionele eisen en (3) randvoorwaarden (Robertson & Robertson, 1999; Pohl, 1997). Met name de eerste twee categorieën zijn omvangrijk. Om het onderzoek uitvoerbaar te houden, dient er een keuze te worden gemaakt. Aangezien de essentie van het RE proces in de functionele eisen ligt, in combinatie met behoefte van Movares en persoonlijke interesse, zal de focus liggen op de categorie van functionele eisen.

Uit voorstudie is gebleken dat het probleem niet uitsluitend de specificatie van eisen het probleem vormt, maar tevens de interactie met de gebruiker en het ontwerp (zie figuur 3). De scope omvat daarom het proces van vertaling van wensen en behoeften van de opdrachtgever naar eisen (nr. 1) en de vertaling van eisen naar een ontwerp (nr. 2). Uit figuur 3 blijkt dat dit met aanvulling van de nummers 3 (decompositie) en 4 (verificatie & validatie) een repeterend proces is. Om deze reden is ervoor gekozen de nummers 1 t/m 4 als scope te kiezen.

figuur 3 – Scope onderzoek voor SE proces Movares (bron: brochure Movares, bewerkt) figuur 2 - Redenen falen technische projecten

(bron: Standish Group in Hull et al., 2005)

2.5 C

2.5.1

Op basis van de in paragraaf 2.1 geïdentificeerde aanleiding binnen de organisatie en wetenschap, in combinatie met de probleemdomeinen als onderzoekscontext, is er een probleemstelling geformuleerd. Deze luidt als volgt:

Het ontbreken van een werkwijze voor een transparant functioneel specificatieproces volgens systems engineering binnen Movares.

2.5.2

Naar aanleiding van de probleemstelling, kan de doelstelling worden geformuleerd. Deze luidt als volgt:

Expliciet beschrijven en verbeteren van het functioneel specificatieproces in de context van systems engineering en het onderzoeken van de haalbaarheid van implementatie binnen Movares.

2.5.3

Centrale vraag 1 – Theoretisch functioneel specificatieproces

Hoe is theoretisch het functioneel specificatieproces expliciet te maken in de context van systems engineering?

a. Op welke wijze kunnen behoeften en eisen van de gebruiker worden geïdentificeerd, opdat transformatie naar systeemeisen mogelijk wordt?

b. Op welke wijze kunnen functionele eisen expliciet worden omgezet in een ontwerp?

c. Op welke wijze dient het proces van verificatie & validatie van het functioneel specificatieproces te verlopen?

Centrale vraag 2 – Huidig functioneel specificatieproces

Op welke wijze wordt in de huidige situatie invulling gegeven aan het functioneel specificatieproces binnen Movares en welke eisen worden vanuit ProRail hieraan gesteld?

a. Welke constateringen kunnen worden gedaan en welke knelpunten kunnen worden geïdentificeerd over de wijze waarop invulling wordt gegeven aan het functioneel specificatieproces binnen de casus Hanzelijn?

b. Welke constateringen kunnen worden gedaan en welke knelpunten kunnen worden geïdentificeerd over de wijze waarop invulling wordt gegeven aan het functioneel specificatieproces binnen de casus HSL-Portugal?

c. Welke verwachtingen en eisen heeft ProRail ten aanzien van het proces van functioneel specificeren voor Movares als opdrachtnemende partij?

Centrale vraag 3 – Verbetervoorstel functioneel specificatieproces

Welke verbeteringen kunnen voor het theoretisch en het huidig functioneel specificatieproces worden benoemd?

a. Op welke punten kan de beschrijving van het theoretische specificatieproces van vraag 1 worden verbeterd na confrontatie met de conclusies van het huidig functioneel specificatieproces?

b. Welke verbeterpunten kunnen worden geïdentificeerd voor het huidig

functioneel specificatieproces, na confrontatie met het theoretisch functioneel

specificatieproces?

Centrale vraag 4 – Haalbaarheid implementatie verbetervoorstel

In hoeverre is implementatie van de verbeterde theoretische procesbeschrijving, voortkomend uit centrale vraag 3, haalbaar binnen Movares?

a. Welke barrières voor implementatie van een functioneel specificatieproces volgens SE kunnen in de praktijk worden geïdentificeerd?

b. In hoeverre sluit de procesbeschrijving aan bij de praktijk?

2.6 O

2.6.1

De centrale vragen en deelvragen hebben de beantwoording van de ‘wat’ vraag afgerond.

Impliciet is hierin een structurering aangebracht door de toekenning van onderzoeksfasen.

Deze onderzoeksfasen zijn in de vorm van producten als uitgangspunt genomen voor het onderzoeksmodel, waarna de relaties zijn gelegd en toevoegingen van activiteiten zijn gedaan. Er is onderscheid gemaakt tussen theoretische (blauw) en empirische (oranje) activiteiten, zodat de aard van deze inzichtelijk wordt (zie figuur 4).

figuur 4 – Onderzoeksmodel

Het onderzoek zal beginnen met het uitvoeren van een literatuuronderzoek, dat moet leiden tot een beschrijving van het theoretisch functioneel specificatieproces. Dit onderdeel zal zich richten op de analyse van de in paragraaf 2.4.2 genoemde relaties. Dit moet resulteren in een expliciete beschrijving van het proces. Vervolgens zal door middel van casestudies het huidige functioneel specificatieproces in kaart worden gebracht. Door de eerste twee onderdelen wederzijds aan elkaar te confronteren, moet duidelijk worden wat er aan beide processen moet worden verbeterd. Uiteraard zal de nadruk liggen op verbetering van het huidige specificatieproces. Uiteindelijk zal dit resulteren in het product van een verbeteringenvoorstel.

Tot slot zal worden gekeken naar de haalbaarheid van implementatie van het

verbetervoorstel. Dit zal worden gedaan middels een expert meeting, waarbij beide processen

zullen worden gesimuleerd. Uit de ervaringen van de experts, kan uitspraak worden gedaan

omtrent de implementatie in de praktijk.

2.6.2

Uit het onderzoeksmodel (zie figuur 4) is gebleken, dat zowel theorie als praktijk onderdeel van het onderzoek zullen uitmaken. Dit vraagt voor de verschillende onderdelen om een passende onderzoeksaanpak c.q. onderzoeksstrategie. Onder een onderzoeksstrategie wordt verstaan het geheel van met elkaar samenhangende beslissingen over de wijze waarop het onderzoek zal worden uitgevoerd (Verschuren & Doorewaard, 2005). Verschuren &

Doorewaard (2005) onderscheiden een vijftal strategieën, te weten: (1) survey, (2) experiment, (3) casestudy, (4) gefundeerde theoriebenadering en (5) bureauonderzoek. Voor de vier producten (zie figuur 4) kunnen aan de hand hiervan de strategieën worden bepaald.

De eerste centrale vraag heeft tot doel te komen tot een theoretische beschrijving van het functioneel specificatieproces. Door de focus op de theorie, waarbij de analyse van literatuur centraal staat, is een keuze voor het bureauonderzoek het meest voor de hand liggend.

Voor de tweede centrale vraag dient het huidig functioneel specificatieproces in kaart te worden gebracht. Daarvoor dient te worden gekeken naar de context waarin de processen in de praktijk tot stand komen. Voor een ingenieurs- en adviesbureau is de projectgewijze werkwijze karakteriserend. Een logische keuze voor de tweede centrale vraag is dan ook de casestudy. Aangezien de casestudies Hanzelijn en HSL-Portugal tot op heden de enige projecten zijn die worden uitgevoerd middels een werkwijze volgens SE, zullen deze worden gebruikt. Verder invulling van de casestudies zal in hoofdstuk 4 worden besproken.

De derde centrale vraag is een confrontatie van de eerste en de tweede centrale vraag. Gezien het analyserende karakter van dit onderdeel, zal hiervoor het bureauonderzoek worden gebruikt. Voor de beantwoording van de laatste vraag, zal een expert meeting worden georganiseerd. Evenals voor de casestudies, zal nader invulling worden besproken in het betreffende hoofdstuk (zie paragraaf 6.3).

Nu de koppeling van de onderzoeksstrategieën met de centrale vragen is gemaakt, kan er een overzicht worden gemaakt waarin tevens de deelvragen een onderzoeksstrategie wordt gekozen. In onderstaande tabel is dit weergegeven.

tabel 1 – Allocatie onderzoeksstrategieën aan centrale vragen en deelvragen Onderzoeksstrategie

Centrale vraag 1 – Theoretisch functioneel specificatieproces

Deelvraag a Bureauonderzoek

Deelvraag b Bureauonderzoek

Deelvraag c Bureauonderzoek

Centrale vraag 2 – Huidig functioneel specificatieproces Deelvraag a Casestudy Hanzelijn

Deelvraag b Casestudy HSL-Portugal

Deelvraag c Interviews en documentenstudie ProRail

Centrale vraag 3 - Verbeteringenvoorstel huidig functioneel specificatieproces

Deelvraag a Bureauonderzoek

Deelvraag b Bureauonderzoek

Centrale vraag 4 – Haalbaarheid implementatie theoretisch functioneel specificatieproces Deelvraag a Expert Meeting/ bureauonderzoek

Deelvraag b Expert Meeting/ bureauonderzoek

3 Theoretisch functioneel specificatieproces

3.1 I

Op basis van het onderzoeksontwerp, kan worden begonnen met het theoretisch functioneel specificatieproces als eerste fase van het onderzoek. Deze fase heeft tot doel antwoord te geven op de eerste centrale vraag, die als volgt luidt:

Hoe is theoretisch het functioneel specificatieproces expliciet te maken in de context van systems engineering?

In het eerste deel van het hoofdstuk (de paragrafen 3.2 t/m 3.5), zal aandacht zijn voor het proces als geheel. Karakteristieken, dimensies, representatie en fasering van het proces zullen aan bod komen. Vooruitlopend op deze beschrijving, zullen de volgende fasen worden onderscheiden: (1) identificatiefase, (2) specificatiefase, (3) ontwerpfase en (4) verificatie- en validatiefase. Op deze fasen zal in de navolgende paragrafen (3.6 t/m 3.9), gedetailleerder worden ingegaan.

Getracht is om de gebruikte literatuur (zoveel mogelijk) in alle fasen terug te laten komen.

Een voorbeeld hiervan is het model van Jackson (Katasanov & Sakkinen, 2006). De reden hiervoor is gelegen in het feit dat de fasen niet apart moeten worden gezien, maar samen een geheel oftewel het specificatieproces vormen.

In paragraaf 3.10 zal deze theorie als input dienen, om te komen tot een modellering van het theoretisch functioneel specificatieproces. Hiertoe is de theorie samengevat in de vorm van kernpunten (zie tabel 5). Op basis hiervan is, als resultaat van de modellering, een procesbeschrijving (zie figuur 17) gemaakt die als uitgangspunt zal dienen voor het verdere onderzoek.

3.2 H

– E

-

Het ontdekken van eisen tijdens het bouwen van het systeem is verre van gewenst, gezien de kosten en inefficiëntie die dit met zich meebrengt (Robertson & Robertson, 1999). De noodzaak voor het specificeren van eisen is in de wetenschappelijke aanleiding in paragraaf 2.3.3 beschreven. Tevens is naar voren gekomen dat RE niet zozeer als een fase moet worden beschouwd, maar moet worden geïncorporeerd in het gehele ontwikkelproces van identificatie van eisen tot en met het ontwerp. Dit wordt ook wel het specificatieproces genoemd. Dit duidt op een integratie van het probleem (behoeften en eisen gebruiker) en de oplossing (het ontwerp). Hoe moet dit worden gezien; kan dit worden verenigd in één proces?

In deze paragraaf zal hier nader op worden ingegaan.

De identificatie van wensen en eisen van de gebruiker enerzijds en de oplossing in de vorm van een ontwerp voor een systeem anderzijds, kan worden gezien als respectievelijk het probleem- en oplossingsdomein (Hull et al., 2005). Het probleemdomein is de omgeving waarin het systeem zal worden gebruikt. Alles draait in dit domein om het krijgen van een antwoord op de vraag: wat moet het systeem doen? Het lijkt een open deur, maar een essentieel kenmerk is dat binnen dit domein oplossingsvrij moet worden gespecificeerd. Het genereren van oplossingen komt namelijk naar voren in het oplossingsdomein. Wanneer in deze context wordt gesproken over oplossingsdomein, worden oplossingen in fysieke vorm door toepassing van technologieën, materialen etc. bedoeld. In paragraaf 3.6 zal hier nader op worden ingegaan.

De aanname van een scheiding tussen eisen en ontwerp, sluit aan bij de definitie van Suh

(1990) van een ontwerp. Suh (1990) stelt dat het ontwerp een weergave is van het

daadwerkelijk te bouwen product, waarbij er continue interactie is tussen het wat en het hoe

dat moet worden bereikt. Een scheiding wordt dus geïmpliceerd tussen het probleemdomein

(wat) en oplossingsdomein (hoe). De scheiding tussen de domeinen wordt explicieter gemaakt

door het ‘Twin Peaks’ model van Nuseibeh (2001), zie figuur 5. Zoals de naam van het model

doet vermoeden, wordt de scheiding expliciet gemaakt door twee piramiden.

figuur 5 - Het ‘Twin Peaks’ model (bron: Nuseibeh, 2001, p. 116, bewerkt)

Er is echter ook een ander aspect in dit model, namelijk de neerwaartse spiraal, aangeduid als ‘specificatie’. In tegenstelling tot de scheiding, impliceert dit nauwe interactie. Dit aspect komt tevens naar voren door de woorden ‘continue interactie’ van Suh (1990). Er is dus niet zozeer sprake van twee aparte, op zichzelf staande domeinen. Wanneer aangenomen zou worden dat er sprake zou zijn van twee onafhankelijke domeinen, zou dit praktisch onmogelijk zijn. Eisen zouden dan niet kunnen worden geïmplementeerd in het product; er is immers sprake van afnemende mate van abstractie naarmate het ontwikkelproces vordert.

Daarnaast is een scheiding onmogelijk doordat het proces van de revisie van producten, niet van voren af aan begint (Katasonov & Sakkinen, 2006).

Samenvattend kan dus worden gesteld, dat het specificatieproces een nauwe interactie is tussen het probleem- en oplossingsdomein, waarbij echter strikte scheiding moet blijven tussen de (oplossingsvrije) eisen en het ontwerp.

Gedurende het specificatieproces dient er uiteraard tot resultaten te worden gekomen. Deze resultaten worden specificaties genoemd. Onder het begrip ‘specificatie’ wordt in het taalgebruik verschillende invullingen gegeven.

Blanchard (1998) geeft aan dat er een viertal soorten specificaties zijn te onderscheiden: (1) systeem- en subsysteemspecificatie, (2) productspecificatie, (3) processpecificatie en (4) materiaalspecificatie.

De specificatie voor het probleemdomein betreft de systeem- en subsysteemspecificatie. In de praktijk wordt dit kortweg specificatie genoemd. Dit is verwarrend, gezien het feit dat er uit het bovenstaande blijkt dat naast deze specificatie nog drie andere soorten zijn. Wanneer dus uitsluitend wordt gesproken van een specificatie, wordt dus een eisen- of systeemspecificatie bedoeld.

Het resultaat aan de oplossingszijde wordt weergegeven in een productspecificatie en een materiaalspecificatie. De laatste wordt echter pas opgesteld op het laagste abstractieniveau.

Veelal wordt alleen van een productspecificatie (ook wel technische specificatie genoemd) gesproken. Voor dit onderzoek zal daarom de term productspecificatie worden aangehouden.

De processpecificatie tot slot, is niet gerelateerd aan een domein maar aan het gehele proces.

Deze specificatie legt dus het specificatieproces vast.

3.3 D

RE

De geschetste scheiding tussen eisen en ontwerp is abstract en dient daarom verder te worden gedetailleerd. Dit kan door het specificatieproces verder op te delen (te scheiden) in fasen. Wanneer echter in dit stadium direct wordt gefocust op de afzonderlijke fasen, zal het overzicht van en daarmee de invloedsfactoren op het gehele proces onduidelijk blijven.

Daarom zal allereerst worden gekeken van welke factoren het RE proces afhankelijk is.

Uit de vorige paragraaf kan worden afgeleid dat het RE proces plaatsvindt binnen het probleemdomein; daar vindt immers de vorming van eisen plaats. Dit probleemdomein kan deze worden voorgesteld als een ‘black box’, waarbij de input van de gebruiker komt en de output als input dient voor het oplossingsdomein (het ontwerp).

Pohl (1994; 1997) onderscheidt een drietal dimensies, die van invloed zijn om tot deze output (de specificatie van eisen) te komen. Deze dimensies zullen in deze paragraaf worden besproken om inzicht te krijgen in het RE proces, die tevens zullen worden gebruikt voor de praktijkstudie in hoofdstuk 4.

In het RE proces, als ‘black box’, vindt een transformatieproces plaats waarbij input wordt omgezet in een output. Hierbij is de input t.a.v. kennis, voorstelling, begrip etc., van het systeem vaag. De output daarentegen moet een concrete specificatie geven van het systeem.

Deze specificatie dient immers als leidraad voor de ontwikkeling van het systeem. Voor de

‘black box’ kunnen een drietal voornaamste doelen worden onderscheiden, namelijk (Pohl, 1994; 1997):

• Verbeteren van een onduidelijk voorstelling van het systeem in een complete systeemspecificatie;

• Transformeren van informele kennis in formele representaties;

• Verkrijgen van overeenstemming over de specificatie vanuit de verschillende perspectieven.

Uit deze doelen zijn door Pohl (1994) een drietal dimensies ontwikkeld, namelijk: (1) specificatie, (2) representatie en (3) overeenstemming. Deze dimensies zullen dus het transformatieproces in de ‘black box’ beïnvloeden en daarmee de wijze waarop tot de output wordt gekomen bepalen. Omgekeerd kan door de dimensies sturing worden gegeven aan het transformatieproces (zie figuur 6).

Om de dimensies beter te begrijpen en concreter te maken, zullen deze apart worden toegelicht. Echter voordat dit wordt gedaan, dient er een aanvulling te worden gedaan op de drie dimensies. Naast specifieke sturing van het transformatieproces, dient ook de omgeving waarin het RE proces plaatsvindt te worden beschouwd. De omgeving kan immers zowel positieve, maar ook een negatieve invloed hebben.

Uit onderzoek van Pohl (1994; 1997) blijkt dat er een vijftal factoren zijn te identificeren die naast de dimensies het RE proces beïnvloeden, namelijk:

• Methode: wanneer er een andere methode wordt gebruikt, kan dit tot verschillende resultaten van het proces leiden, doordat de focus van de methoden verschilt. Zo zal toepassing van een ‘structured analysis’ een andere specificatie tot resultaat hebben dan wanneer er een ‘object oriented analysis’ wordt gebruikt.

• Tools: toepassing van tools beïnvloed de specificatie. Wanneer bijvoorbeeld een redenatietool wordt toegepast, kunnen inconsistenties worden geïdentificeerd die anders niet naar voren waren gekomen.

• Sociale aspecten: de sociale aspecten van het RE team beïnvloed de resultaten.

Samenwerking tussen de personen heeft hiermee invloed op het eindresultaat.

• Cognitieve vaardigheden: personen hebben verschillende cognitieve vaardigheden.

Wanneer specialisten worden betrokken in het RE proces, zal dit leiden tot een betere specificatie.

• Economische randvoorwaarden: deze beïnvloeden de resources (geld, mensen etc.) die

kunnen worden gebruikt/ingezet gedurende het RE proces.

Het moge duidelijk zijn dat deze (externe) factoren niet uniek zijn voor het RE proces.

Productieprocessen worden namelijk ook door deze omgevingsfactoren beïnvloed. Wanneer in de praktijkstudie (hoofdstuk 4) zal worden gekeken naar de knelpunten die zich voordoen binnen het RE proces, dienen knelpunten die voorkomen uit het RE proces te worden gescheiden van de knelpunten die gerelateerd zijn aan de omgeving. Analyse van knelpunten binnen het RE proces, dienen dus uitsluitend te worden gerelateerd aan de drie dimensies.

figuur 6 – De drie dimensies van het RE proces (bron: Pohl, 1994, p. 249)

Specificatie dimensie

De dimensie van specificatie is gerelateerd aan de mate van inzicht in de eisen op een gegeven tijdstip. Afhankelijk van de situatie, zijn de specificatie van het systeem en de omgeving in het begin van het RE proces vaag. Het doel is om de behoefte om te zetten in een complete systeemspecificatie door een iteratief proces van definitie en validatie. Hiervoor moet de dimensie een aantal karakteristieken hebben, die hierna zullen worden besproken (Pohl, 1994; 1997).

De specificaties moeten weergeven w at het systeem zou moeten doen (en dus niet hoe ). De beantwoording van deze ‘wat’ vraag dient te worden gespecificeerd in functionele eisen. De niet-functionele eisen daarentegen geven een beschrijving van de prestatie, ontwerp voorwaarden (randvoorwaarden), externe interfaces en kwaliteitsattributen

.

Naast deze classificatie dient er onderscheid te worden gemaakt in zogenoemde vitale eisen en eisen van wensende aard. Aan vitale eisen moet door het systeem volledig worden voldaan, waarbij voor de eisen van wensende aard aan kan worden voldaan wanneer dit inpasbaar is binnen de getelde beperkingen (lees één of meerdere van de hierboven genomen factoren uit de omgeving) (Pohl, 1994; 1997).

Samenvattend kan worden gesteld dat het eerste hoofddoel van RE is het maken van een specificatie. De mate van specificatie, vaag of gedetailleerd, wordt samengevat in de dimensie van specificatie.

Representatie dimensie

De dimensie van representatie betreft de verschillende representaties die worden gebruikt voor het uitdrukken van kennis van het systeem. Hierbinnen kunnen een drietal categorieën worden onderscheiden (Pohl, 1994): (1) informeel, (2) semi-formeel en (3) formeel.

De eerste categorie bevat willekeurige (grafische) weergaven, “natuurlijke talen” en

beschrijvingen door voorbeelden. De creativiteit in deze categorie is groot door de mogelijke

vrijheid. De tweede categorie bevat representaties als ‘Entity Relationship Diagrams’ (ER-

Diagrams) en ‘Structured Analysis and Design Technique’ (SADT-diagram) etc. Deze

representaties moeten een duidelijk beeld en overzicht van het systeem geven. Voor de derde

categorie tot slot, kunnen formele specificatie “talen” worden gebruikt als VDM (the Vienna Definition Language). Ten opzichte van semi-formele representaties, zijn formele representaties semantisch van aard, waardoor meer standaardisatie van het systeem mogelijk wordt (Pohl, 1994; 1997; Hull et al. 2005).

De keuze voor het gebruiken van een bepaalde representatie hangt ten eerste af van de persoonlijke voorkeuren. De systeemgebruiker en systeemontwikkelaar kijken immers vanuit een verschillende perspectieven naar het systeem. Ten tweede hangt het af van het stadium waarin de specificatie zich bevind. Veelal wordt er gewerkt van informeel naar formeel naarmate het proces vordert. Wanneer verschillende representaties worden gebruikt, moet aandacht worden gegeven aan consistentie tussen dezen (Pohl, 1994; 1997).

Samenvattend kan worden gesteld dat gedurende het RE proces verschillende representaties worden gebruikt. Ten eerste zal aan het begin van het proces de kennis van het systeem worden uitgedrukt in informele representaties, dat zal resulteren in formele representaties.

Ten tweede moet de transformatie tussen de verschillende representaties (informeel naar formeel) door het proces mogelijk worden gemaakt. Ten derde moeten de verschillende representaties onderling consistent zijn (Pohl, 1994; 1997).

Dimensie van overeenstemming

De derde dimensie beschrijft de mate van overeenstemming die is bereikt over de specificatie. In het begin van het proces heeft een ieder een eigen perspectief van het systeem. Sommige eisen worden gedeeld door het team, maar de meeste eisen komen voort uit de rollen die de personen vervullen

. Betrekking van verschillende perspectieven heeft een positief effect op het RE proces. Hierdoor wordt een goede basis gevormd wanneer de eisen moeten worden geïdentificeerd. Dit draagt bij aan de eis aan eisen van compleetheid (zie paragraaf 3.7.5). Tevens kan het bereiken van overeenstemming ook worden gezien als vroegtijdige validatie; immers wanneer er inbreng is van eisen vanuit verschillende perspectieven, zal het uiteindelijke product ook meer aansluiten bij de wensen en behoeften van de gebruiker. Wanneer tegengestelde behoeften zijn geïdentificeerd, kunnen conflicten worden geïdentificeerd en overeenstemming hierover worden bereikt. Dit betekent dus niet dat alle eisen sowieso worden geïncorporeerd. Door communicatie tussen de partijen moet hier worden uitgekomen (Pohl, 1994; 1997)

Samenvattend kan worden gesteld dat het incorporeren van verschillende perspectieven (belangen) in het RE proces, een positief effect op de specificatie van eisen. Overeenstemming bereiken kan hiermee worden gezien als derde hoofddoel van RE.

2 Zie voor een uitgebreide beschrijving van de perspectieven en vervulling van rollen binnen SE, het artikel ‘Twelve systems engineering roles’ van Sheard (1995).

3.4 R

Er is een algemene misvatting dat RE slechts een enkele fase beslaat in het product ontwikkelingsproces. RE heeft een vitale rol in elke fase van de life-cycle van het proces (Hull et al., 2005). Over de representatie van het RE proces, zijn echter verschillende interpretaties.

Easterbrook (2004) geeft terecht aan dat er niet één beste representatie van een eisen life- cycle is, omdat dit context afhankelijk is voortkomend uit de grote variëteit aan projecten.

Vanuit de context van SE, is in de literaire voorstudie voor het onderzoeksvoorstel het procesmodel voor het SE proces vastgesteld (zie figuur 38, Bijlage 1). Aangezien de focus van het onderzoek op het voortraject ligt, dient er een gedetailleerdere representatie van het proces te worden gebruikt, die als uitgangspunt dient voor het uiteindelijke procesmodel (zie paragraaf 3.10).

Blanchard (1998) beschrijft drie bekende procesmodellen, namelijk: (1) watervalmodel, (2) spiraalmodel en (3) V-model. Hieronder zullen deze modellen qua eigenschappen kort worden besproken. Het doel hiervan is een representatie te kiezen die zal worden gebruikt voor de beschrijven van het theoretische specificatieproces. Bij de beschrijving van de modellen gaat het om de uitgangspunten waarop de modellen zijn gebaseerd; het doel van deze modellen zijn immers gelijk aan het SE procesmodel, omdat alle representaties de gehele life-cycle beschrijven. Het SE procesmodel is echter te abstract om concrete procesbeschrijving voor de specificatie mogelijk te maken.

Watervalmodel (Royce)

Het watervalmodel (figuur 7) is geïntroduceerd door Royce in 1970, bedoeld voor de ontwikkeling van software. Het watervalmodel is het meest bekende, maar ook het meest simplistische life-cycle model.

Oorspronkelijk bestond het model uit vijf fasen, die door Boehm is uitgebreid tot acht.

Hierin wordt stapsgewijs het idee gedetailleerd, waarna het systeem

wordt getest en geïmplementeerd. Door wijzigingen in (een) fase(n), is

revisie van voorgaande fasen

noodzakelijk, die kunnen zijn voortgekomen uit onvoorziene problemen. De zwakke punten van dit model liggen met name in de simplistisch ideale benadering, die slechts beperkt geldig zijn door de genomen restrictieve aannames. Het voornaamste uitgangspunt is dat eisen kunnen worden beschreven in het begin van het project en vervolgens worden

‘bevroren’ voor de rest van het project (Easterbrook, 2004).

Reeds is aangegeven dat requirements engineering een dynamisch proces is dat gedurende de gehele ontwikkeling verandering en/of aanvulling benodigd. Het ‘bevriezen’ van eisen is dan ook, in deze tijd, een onrealistische aanname.

Spiraalmodel (Boehm)

Het spiraalmodel (figuur 8) is door Boehm ontwikkeld in 1989. De intentie van het model is het introduceren van een benadering dat gebaseerd is op risico’s voor de ontwikkeling van productsystemen. Het proces verloopt iteratief en doorloopt (repeterend) verschillende fasen, waarin verschillende producten worden gerealiseerd. Hierdoor wordt evaluatie van risico’s mogelijk voordat verder wordt gegaan naar een volgende fase (Blanchard, 1998). Door het iteratieve proces ‘groeit’ de spiraal, waarmee kennis en ervaring kenbaar wordt gemaakt.

figuur 7 - Watervalmodel (bron: Blanchard, 1998, p. 30)

Het principe uit het watervalmodel om van behoefte tot detail en uiteindelijk tot implementatie te werken, komt duidelijk terug. Door risicoanalyse wordt een reductie van de risico’s mogelijk, alleen is er echter in het proces geen mogelijkheid tot terugkoppeling.

V-model (Forsberg & Mooz)

Het V-model (figuur 9) is ontwikkeld door Forsberg & Mooz en beschrijft wat zij noemen “the technical aspects of the project” (Blanchard, 1998). Het model begint met een beschrijving van de behoeften van de gebruiker en eindigt met een tegen de behoeften van de gebruiker gevalideerd systeem. Aan de linkerzijde komt door decompositie van systeem- naar componentniveau het ontwerp tot stand, die aan de rechterzijde van component tot systeemniveau worden geïntegreerd. Hierin staat verificatie en validatie (in figuur ‘testing’) centraal om ervan verzekerd te zijn dat de (sub-)systemen en componenten aansluiten bij de specificaties. Een kenmerkend aspect van deze representatie is de scheiding tussen tijd en mate van abstractie. In het watervalmodel zijn deze eenheden ineengeschoven, waardoor gedurende het proces veel verwarring ontstaat over de mate van detail (Easterbrook, 2004).

Wanneer revisie in het watervalmodel nodig is, wordt er een stap terug gedaan en daarmee ook in de tijd. Wanneer echter in het V-model uitvoering van activiteiten op een ander abstractieniveau noodzakelijk is, wordt niet zozeer de voortgang van het project beïnvloed (Easterbrook, 2004).

Kijkend naar de genoemde modellen, zal het principe van het V-model voor het onderzoek worden gebruikt. Een argument hiervoor is de mogelijkheid van het expliciet maken van het decompositieproces. Uit de verkennende voorstudie van het SE domein (zie Bijlage 1), is gebleken dat dit een essentieel aspect is van het SE proces. Tevens is de keuze gebaseerd op de noodzaak om RE gedurende de gehele productontwikkeling te betrekken en niet zozeer te beschouwen als een fase. Het V-model voldoet hieraan, waarbij het de mogelijkheden biedt om de specificatie van eisen gedurende het gehele proces te wijzigen of aan te vullen, zonder dat dit enorme impact heeft op de voortgang van het project.

Wel dient te worden opgemerkt dat de keuze voor het V-model niet betekent dat die ook in deze verschijningsvorm zal worden gebruikt; immers ligt de scope van het onderzoek niet op de gehele life-cycle, maar uitsluitend op het RE proces en het ontwerp. Als variant van het in figuur 9 genoemde V-model, zal een andere uitwerking worden gebruikt op basis van figuur 3, genoemd in paragraaf 2.4.2.

figuur 9 - V-model (bron: Blanchard, 1998, p. 31) figuur 8 - Spiraalmodel (bron:

Blanchard, 1998, p. 31)

3.5 F

In de vorige paragraaf zijn impliciet keuzes gemaakt voor (abstracte) faseringen die de keuze van het V-model met zich meebrengt (zie figuur 9), namelijk: definiëren systeemspecificatie, alloceren systeemfuncties in subsystemen, detail ontwerp van componenten en verificatie &

validatie van het systeem.

Aangezien de keuze voor de fasering een essentiële ontwerpkeuze is, zullen mogelijke faseringen worden bekeken, voordat een definitieve keuze voor de faseringen wordt genomen. Zoals in paragraaf 2.4.2 is aangegeven, zal het proces uitsluitend de specificatie van eisen in interactie met het ontwerp op de verschillende systeemniveaus omvatten.

Aangezien de processen van specificeren en ontwerpen op elk niveau gelijk is, zal het ontwerp van de fasering zich richten op de chronologie van activiteiten binnen één niveau.

Wanneer wordt teruggegaan naar de opzet van het onderzoek, dan is gesteld dat het RE proces verloopt in de context van het SE proces. De fasering zal daarom eerst vanuit het SE perspectief worden benaderd.

Binnen organisaties waar SE wordt toegepast, ligt binnen de disciplines veelal de intentie om een (sub)optimaal product te leveren. Hierbij wordt dus niet vanuit de synergetische benadering gedacht dat de som van de delen tezamen meer is dan de som der delen afzonderlijk. Vanuit deze gedachte zou de onderkenning moeten zijn dat de systeemeisen anders (kunnen) zijn dan de eisen die voortkomen uit een discipline en zou als uitdaging in de systeemontwikkeling moeten worden gezien. Werken volgens de SE benadering vraagt daarmee om communicatie tussen de verschillende disciplines, waarbij wordt gestreefd naar een gezamenlijk doel (INCOSE, 2004). De strategie die de SE benadering hanteert om dit gezamenlijke doel te bereiken is gebaseerd op de volgende punten (INCOSE, 2004):

• Begrijpen van een probleem voordat er wordt getracht deze op te lossen;

• Onderzoeken van alternatieve oplossingen;

• Verifiëren van de geselecteerde oplossing correct is voordat met de oplossing wordt verder gegaan.

Wanneer deze punten worden omgezet in concrete procestaken, dan kunnen de volgende fasen (chronologisch) worden onderscheiden. Om een goed beeld te krijgen van de verschillende literatuur, zijn de fasen van INCOSE (2004) en Blanchard (1998) naast elkaar gezet; beide vanuit het perspectief van SE.

tabel 2 – Faseringen in SE proces volgens INCOSE (2004) en Blanchard (1998)

INCOSE (2004) Blanchard (1998)

1. Definiëren systeem doelen (gebruikers

behoeften); Indicatie behoefte gebruiker en eisen analyse 2. Vaststellen functionaliteit (functionele

analyse); Functionele analyse

3. Vaststellen prestatie-eisen (eisen analyse); Eisenallocatie 4. Incrementeel ontwerp en operationele

concepten (architectuur synthese); Trade-off studies 5. Selecteren baseline (kosten/batenanalyse); Synthese 6. Verifiëren baseline aan (gebruikers)eisen; Evaluatie

7. Valideren baseline aan behoeften gebruiker; Productspecificatie

8. Decompositie proces Ontwerpreviews en decompositie proces

Het zou legitiem zijn om vanuit dit perspectief de fasen voor dit onderzoek vast te stellen, omdat dit onderzoek immers wordt uitgevoerd in de context van SE. Het is echter interessant te kijken, of er ook verschil zit in het specificatieproces vanuit een ander perspectief.

In ‘The principles of design’ door Suh (1990), wordt vanuit een algemener standpunt gekeken

naar de fasering, namelijk uitsluitend gericht op het totstandkomen van het ontwerp (zie

figuur 10). Een korte toelichting zal hierop worden gegeven.

figuur 10 – De ontwerploop – meer effectieve synthese vereist grotere creativiteit, sterkere analyse en verbeterde onderbouwingen voor besluiten (bron: Wilson in Suh, 1990, p. 27)

Vanuit de behoefte komen functionele eisen tot stand, waarna door ideeën (brainstorm) wordt gekomen tot een product (‘ideate & create’). Dit product wordt vervolgens geanalyseerd en geverifieerd aan de functionele eisen (‘analyse and/or test’). Wanneer dit product niet volledig voldoet aan de gespecificeerde eisen, dan moet er met een nieuw idee worden gekomen, of wijziging in de functionele eisen om de daadwerkelijke behoefte beter weer te geven.

Wanneer deze procesbeschrijving naast die van de in tabel 2 genoemde fasering wordt gehouden, kan worden geconcludeerd dat deze in hoofdlijnen overeenkomen; details als selectie van een baseline daargelaten.

Samenvattend kan dus worden gesteld dat de fasering van initiatie, specificatie, ontwerp en verificatie & validatie niet alleen in de context van SE wordt gevolgd, maar ook wordt toegepast vanuit een algemener ontwerpperspectief. Kenmerkend voor beide beschrijvingen is de iteratieve aard van het proces. Qua inhoud en chronologie komen de faseringen van het proces dus in hoofdlijnen, vanuit de verschillende perspectieven, overeen.

Op basis van deze theorie, kan worden gekomen tot een voor het specificatieproces te volgen fasering. Echter zou het, terugkomend om de drie dimensies van het RE proces, interessant zijn te weten welke dimensie in welke fase “actief” is, om zo meer inzicht te krijgen in de aard van de betreffende fase. Pohl (1997) heeft in aanvulling op het onderscheiden van de dimensies, taken uit de verschillende fasen van het RE proces aan de dimensies gekoppeld (zie figuur 11).

figuur 11 – De vier taken van RE en de voornaamste invloed op de dimensies (bron: Pohl, 1997, p. 26)

In aanvulling op het uitsluitend onderscheiden van de fasen met de taken voor het specificatieproces, zullen ook de dimensies aan de fasen worden gekoppeld (zie tabel 3).

De kanttekening die dient te worden gemaakt, is het feit dat figuur 11 uitsluitend over het

RE proces gaat, terwijl in tabel 3 tevens het ontwerp is opgenomen. In paragraaf 3.9 zal

blijken dat verificatie & validatie niet uitsluitend na het specificatieproces hoeft te komen,

maar ook na het ontwerp kan worden uitgevoerd. Hierdoor wordt het legitiem om toepassing van de dimensies te koppelen aan de faseringen.

tabel 3 – Fasering theoretisch specificatiemodel

Fase Taak Dimensie

Identificeren behoeften en eisen

gebruiker en stakeholders Specificatie 1. Identificatiefase

Overeenstemming bereiken over

(conflicterende) eisen Overeenstemming 2. Specificatiefase Functionele analyse en specificatie

(incl. vaststellen prestatie-eisen) Representatie Allocatie eisen

Uitvoeren variantenstudies 3. Ontwerpfase

Vaststellen productspecificaties

Representatie en specificatie

4. Verificatie & validatiefase Verificatie & Validatie Alle drie

5. (Decompositie) Afleiden eisen n.v.t.

Tot slot dient er voor de duidelijkheid nog een toelichting te worden gegeven op de eerste en de laatste fase. In tegenstelling tot de genoemde dimensie van specificatie voor de taak van identificatie uit figuur 11, is deze voor de fasering aangevuld met de dimensie van overeenstemming. Dit komt voort uit het feit dat onder de identificatiefase niet alleen het identificeren van de eisen wordt verstaan, maar juist ook het overeenkomen van deze eisen met de gebruiker en stakeholders.

Als toelichting op de laatste “fase” dient te worden opgemerkt dat hier geen dimensie aan is toegekend, omdat het afleiden van eisen in principe overeenkomt met de eerste fase. Het wordt dan dus ook niet zozeer als een fase gezien, maar als een stap die cirkel van het proces rond maakt. In de beschrijving van de fasen in de volgende paragrafen zal daarom de

“decompositiefase” worden geïntegreerd in de fase van verificatie & validatie.

In de volgende paragrafen 3.6 t/m 3.9, zal ontwerpenderwijs invulling worden gegeven aan de

fasen. Om deze fasen in perspectief en in relatie tot elkaar te zien, zal het model van Jackson

(in Katasonov & Sakkinen, 2006) worden gehanteerd. Dit model zal in elke fase van het proces

terugkeren.