Kennisplatform CROW Online Kennisbank

Heeft u vragen? U kunt ons ook bellen op tel: 0318-695315

Interesse?

Neem een abonnement op Specificeren / Systems Engineering

Praktijkvoorbeeld Systems Engineering
Deze tekst is gepubliceerd op 18-06-15

Stap 1: eisenanalyse

De eisenanalyse levert de eisenstructuur op voor de uitwerking van de aanbieding. Deze moeten we bepalen conform het format dat de opdrachtgever wenst. Om dit overzichtelijk en gestructureerd te laten verlopen, gebruiken we de volgende stappen:
  1. Eisen invoer;
  2. Eisen koppelen aan concept-object structuur uit VS 1 en/of activiteitenstructuur VS 2;
  3. Toewijzen verantwoordelijke voor object en activiteit. Een optie is gebruik te maken van een objecttypestructuur, als volgt: Voorbeeld structuur objecttype:
    Object Object_type
    Weg 1Weg
    Weg 2
    Weg 3
    Voordeel van een objecttypestructuur is dat algemene eisen van een object weg behorende tot objecttype weg, slechts 1× geverifieerd hoeft te worden in plaats van meerdere keren.

  4. Eisenanalyse per object. Dit levert:
      -vragen aan de opdrachtgever;
      -vragen intern;
      -risico’s;
      -wijzen van acceptatie.
  5. Optioneel is om de eisenanalyse te combineren met de opzet van het verificatieplan. Bij de eisenanalyse wordt uitgegaan van de volgende indeling van eisen:
      -Eisencode – Door elke eis te voorzien van een unieke identificatiecode, borgen we de onderlinge relaties tussen verschillende eisen. Zo kan een hoofdeis diverse onderliggende eisen bevatten. Door dit logisch te nummeren, ontstaat een overzichtelijke structuur.
      Als voorbeeld de volgende reeks eiscodes:
      Eis 01 Hoofdeis
      Eis 01.1 Onderliggende eis
      Eis 01.1.1 Onderliggende eis
      Eis 01.2 Onderliggende eis
      Eis 01.3 Onderliggende eis
      Eis 02 Hoofdeis
      Deze lijst toont de hoofdeisen met onderliggende eisen tot drie niveaus. De opdrachtgever heeft in zijn eisenspecificatie vaak al een bruikbare unieke codering vastgelegd.

      Eisbeschrijving – Beschrijving van de eis bevat een titel en/of een toelichting, met vermelding van de eisinitiator. De opdrachtgever heeft in zijn eisenspecificatie hiervoor al een bruikbaar format vastgelegd. Na ontwerpkeuzes volgens de afgesproken codering en beschrijving eisen afleiden van de bestaande set en toevoegen.
      -Objecten – Een object bestaat uit veel verschillende deelobjecten; dit kunnen constructieve onderdelen zijn maar ook disciplinegerichte onderdelen, zoals werktuigbouwkundige, bouwkundige of elektrische onderdelen. Door de objecten binnen de scopeafbakening in een project eerst logisch in een objectstructuur vast te leggen, kunnen hieraan de eisen gekoppeld worden via een toedelingsmatrix. Hierdoor wordt duidelijk welke eisen bij welk objectdeel horen en weten we ook of elk object wel eisen bevat en of alle eisen wel toegewezen zijn aan objecten. Bij elk object hoort een unieke objectcodering en een objectdefinitie; deze beschrijft waar het object betrekking op heeft, zodat voor externen duidelijk is wat met het object bedoeld wordt.
De eisenspecificatie uit de vraagspecificatie is gekoppeld aan een structuur van objecten, in dit geval bestaande uit een lijst objecttypen. Hiervan moeten we eerst een objectstructuur maken. De objectstructuur is bruikbaar in het gehele ontwerp- en realisatieproces, maar ook de daaropvolgende fasen.
Voorbeeld objectstructuur onderdoorgang Nootdorp
Objectstructuur
Het systeem uit de vraagspecificatie omvat een 17-tal objecten. Op grond hiervan is een structuur opgesteld. Het is belangrijk een goede en duidelijke indeling te maken van de verschillende objecten. In SE-termen gaat het hier om een hiërarchische structuur met verschillende objectniveaus, systeem, subsystemen, componenten, et cetera. Zie figuur 11.
[ link ]

Figuur 11. ObjectstructuuronderdoorgangNootdorp

Functiestructuur
De vraagspecificatie laat naast een lijst met 17 objecten ook twee functiestructuren zien in de vorm van functiebomen gekoppeld aan twee topeisen. Omdat het belang van de opdrachtgever is dat aan alle functies wordt voldaan, zijn de eisen gekoppeld aan functies en aan objecten. De eisen zijn nu de centrale spil. Voorwaarde is dan wel dat elke functie en elk object aan minimaal één eis wordt gekoppeld en omgekeerd. Is dit niet zo, dan vragen we ons af of eis, object of functie wel relevant is.
Leerervaring opdrachtnemer
Complicaties
De objectstructuur is vanuit een component- en uitvoeringsgerichte benadering bottom-up samengesteld, gebruikmakend van het referentieontwerp. De raakvlaksituaties met bestaande systemen, zoals verschillende wegstructuren, mi lieustructuur, waterstaatsstructuur, et cetera, zijn niet weergegeven. Dit kan later problemen opleveren bij het integraal afwegen van de verdere uitwerking van het project. Tijdens de uitvoering kwam dit inderdaad naar voren, zoals extra ontwerpwerkzaamheden om de wegaansluiting nieuw naar bestaand, uitwerken van onderdelen van het waterstaatssysteem, et cetera. Een systeem bestaat immers uit componenten met hun relaties. Die relaties bepalen de systeemsamenhang en moeten benoemd zijn om een integrale afweging mogelijk te maken. In de objectstructuur van de onderdoorgang Nootdorp zien we wel een opdeling in subobjecten en componenten, maar de aard en het type relaties is niet duidelijk gemaakt. Het uitwerken van delen van een objectstructuur betekent dat er relaties doorsneden worden, horizontaal dan wel verticaal en dan is het van belang te weten wat er op die raakvlakken gebeurt. Als we daar onvoldoende rekening mee houden, lopen we risico’s die we pas tegenkomen als we de uitwerkingen samenstellen tot een geheel, met alle gevolgen van dien.
Oorzaken
  • Het is een misvatting dat we ervan uitgaan dat het SE-proces beheersbaar wordt door de nadruk te leggen op een topdowngerichte ontrafeling en opdelingen van eisen, functies en objecten. De systeemgedachte gaat verder en benadrukt juist het benoemen van aard en type van de relaties en daarmee het vastleggen van raakvlaksituaties, waardoor een integrale afweging beter onderbouwd kan worden.
  • Engineers zijn gewend zaken te ontrafelen en op te delen in beheersbare eenheden. De vele disciplines in engineering versterken deze gedachte nog eens, omdat we ze zien als een organisatorische opdeling van technologieën. Engineers zijn gewend aan projectmatig werken, waarin opdeling tot beheersbare zelfstandig uit te werken onderdelen centraal staat.
Remedie Systems Engineering
Als multifunctioneel team starten met het uiteenrafelen van objecten en benoemen van hun relaties door raakvlaksituaties te onderkennen. Een hiërarchische structuur gebruiken om de opdeling, relaties en raakvlaksituaties onderling vast te leggen, gekoppeld aan de verantwoordelijke teamleden. Op deze wijze decomponeren van de objecten geeft meer overzicht, traceerbaarheid en transparantie hoe objecten met elkaar samenhangen om de systeemwaarde te bereiken. Enerzijds wordt hiermee de complexiteit gereduceerd, zoals engineers gewend zijn, maar anderzijds ook vergroot door het beheersbaar maken van de onderlinge relaties en raak- vlaksituaties.
SE betekent dus niet alleen top-down ontrafelen maar tegelijkertijd bottom-up genereren van een logische samenhang tussen wat ontrafeld is. Dat is ontwerpenderwijs decomponeren ofwel opdelen van een geheel in delen door je steeds af te vragen of de samenhang van de delen het geheel (de systeemwaarde) nog wel weergeven en borgen. De analyse is dus niet alleen gericht op het opdelen, maar ook op de samenhang van wat opgedeeld is.

Eisen zijn te herleiden naar functies van een object. Een functie zegt iets over één of meerdere eisen en levert een overzichtelijke omschrijving van de eis. Een functie kan ook aan één of meerdere objecten gekoppeld zijn. Eisen kunnen dus van een bepaald type zijn en daar moeten we in het project rekening mee houden.
We onderscheiden in dit voorbeeld de volgende vijf typen eisen:
  • Functie-eis: Beschrijving van een basiseigenschap van een object/systeem gedurende zijn levensduur, zoals ‘dragen belasting’ of ‘kruisen verkeersstroom’. Elk alternatief of elke variant moet aan alle functie-eisen voldoen om aanvaardbaar te zijn.
  • Aspecteis: Beschrijving van de mate waarin de functie van het object aan de eisen moet voldoen. Deze eisen hebben betrekking op zaken zoals mate van betrouwbaarheid, beschikbaarheid, instandhouding, veiligheid en vormgeving. Ze stellen voorwaarden aan de prestaties en leggen voorwaarden op aan systemen. Op deze manier worden de voornaamste risico’s inzichtelijk. De mate waarin alternatieven of varianten aan aspect eisen voldoen, kunnen verschillen en dat maakt uit welke keuze er in een integrale afweging (trade-off) gemaakt kan worden. Alternatieven of varianten worden dus afgewogen op basis van aspecteisen nadat eerst aangetoond is dat ze aan alle functie-eisen voldoen. Aspecteisen zijn vaak te koppelen aan ondersteunende functies ten behoeve van de basisfuncties.
  • Interne raakvlakeis: Dit kunnen functio nele of aspecteisen zijn die de relatie tussen de verschillende levenscycli weergegeven en de verbanden tussen werkzaamheden binnen objectgrenzen van een project. Bij grote werken waarbij meerdere objecten gerealiseerd worden of na elkaar gerealiseerd gaan worden, is dit type eis van belang.
  • Externe raakvlakeis: Deze eisen zijn aspecteisen of functie-eisen vanuit de omgeving die voorwaarden of eisen opleggen aan het nieuw te ontwikkelen systeem. Hierbij moet niet alleen gekeken worden naar objecten, maar ook naar aspecten als procesovergangen en toekomstige werkzaamheden, bijvoorbeeld eisen ten aanzien van het aansluiten van de bestaande infrastructuur met een te realiseren infrastructuur.
  • Realisatie-eis: Deze eisen zijn vaak voorwaarden waaraan de realisatie moet voldoen, zoals buitendienststellingen van het spoor, verlagen van grondwaterstanden of afdammen van watergangen, et cetera. Als zodanig zijn ze te beschouwen als aspect- eisen ten aanzien van maakbaarheid. Bij het ontwerpen maar ook de keuze van een ontwerp zijn deze eisen van belang.
Voorbeeld type eisen onderdoorgang Nootdorp
  • Functie-eis
      -Onderdoorgang Nootdorp dient te zorgen dat verkeer de omgeving kan kruisen zonder hinder, in overeenstemming met het bestemmingsplan ter plaatse;
      -Onderdoorgang Nootdorp dient het fiets- en voetgangersverkeer, dat van de onderdoorgang gebruikmaakt, te geleiden.
  • Aspecteis
      -Onderdoorgang Nootdorp dient dusdanig betrouwbaar te zijn dat verkeer conform prognose en planning kan worden afgewikkeld;
      -Onderdoorgang Nootdorp dient, met inachtneming van het benodigde onderhoud en toegestane onbetrouwbaarheid, 100 procent beschikbaar te zijn voor de afhandeling van al het verkeer.
  • Interne raakvlakeis
      -Vanuit de opdrachtgever zijn er geen interne raakvlakeisen gesteld; deze zullen wel binnen het bouwbedrijf gaan ontstaan omdat tijdens de buitendienststelling, waarin het werk moet worden gerealiseerd, alle activiteiten tegelijk plaatsvinden. Dit dient goed gemanaged te worden.
  • Externe raakvlakeis
      -Onderdoorgang Nootdorp dient zodanig aan te sluiten op de bestaande en toekomstige infrastructuur op de systeemgrenzen dat de functionaliteit gewaarborgd blijft of wordt gerealiseerd;
      -Onderdoorgang Nootdorp dient zodanig te zijn aangesloten op de bestaande en voorbereid te zijn op toekomstige railinfrastructuur op de systeemgrenzen, zoals weergegeven op het Definitief ontwerp – Bovenaanzicht systeemgrenzen, dat de huidige en toekomstige functionaliteit van de treinexploitatie gewaarborgd blijft.
  • Realisatie-eis
      -Tijdens de realisatie van onderdoorgang Nootdorp dient te worden voldaan aan afspraken met derden en voorwaarden;
      -Tijdens de realisatie van onderdoorgang Nootdorp dient de treinexploitatie, met uitzondering van de geplande buiten- dienststellingen en treinvrije periodes, niet verstoord te worden.
Voorbeeld eisenstructuur onderdoorgang Nootdorp
De categorieën en type eisen zijn door de opdrachtgever aangeleverd; voor de objecten is een objectstructuur opgesteld. De opdrachtgever heeft nagedacht over de functies (categorieën) waaraan het project moet voldoen en heeft daaraan eisen gekoppeld en bindende en informatieve referenties toegevoegd. In tabel 7 is een gedeelte van de eisenanalyse weergegeven.
Tabel 7. Gedeelte uit rapportage eisenanalyse
Eisenanalyse Projectnaam: Onderdoorgang ’s-Gravenweg te Nootdorp
Projectnummer:
Status:
Datum:
Versie:		 6.296.24
Concept
28-4-2010
1
Gesorteerd opobject: Tunnel A12
Objectdefnitie: Dit gedeelte in het tunnelvak onder de A12. Het betreft de algemene eisentot dit gedeelte.
Categorie Beschikbaarheid
Eisomschrijving Object Type eis
OGN B1 OGN dient, met inachtneming vanhet benodigde onderhoud entoegestane onbetrouwbaarheid,100% beschikbaar te zijn voor deafhandeling van al het verkeer. Tunnel A12; Verharding Aspecteis
OGN B1.2 OGN dient, met inachtneming vanvernieuwingen, 100% beschikbaarte zijn voor afhandeling van hetwegverkeer. Tunnel A12; Verharding Aspecteis
OGN B2 Alle onderdelen, met inachtneming van het benodigde onderhoud, dienen in stand te blijven. Tunnel A12;
Tunnelspoorovergang;
Tunneltussengedeelte;
Tunneluitmondingen.		 Aspecteis
Afleiden van eisen en wijzigingen
De SE-werkwijze gaat uit van een eisengestuurd engineeringsproces. Een oplossing op een bepaald systeemniveau is geverifieerd op basis van de eisen op dat niveau. Bij verdere uitwerking op een lager systeemniveau zijn afgeleide eisen uit de eisen en oplossing van het voorgaande systeemniveau van belang. Het afleiden van eisen en het genereren van daarbij behorende oplossingen kan vanuit de systeemgedachte aanleiding zijn tot het heroverwegen van eisen en oplossingen op het voorgaande niveau. Dit eisengespecificeerd ontwerpen is nieuw ten opzichte van het traditionele proces. Vanuit projectmatig werken gingen we er immers vanuit dat eisen behoren bij een bepaald niveau en heroverweging van eisen en oplossingen uit voorafgaande niveaus niet plaatsvindt dan slechts in zeer bijzondere situaties. In een SE-werkwijze ligt juist de kracht tot verrijking van de systeemwaarde in terugkoppelmogelijkheden over niveaus heen. Hierbij hoort een systematische en dus gestructureerde, expliciete, transparante en traceerbare weerslag van de eisen en oplossingen. De status van nieuwe, gewijzigde en vervallen eisen moet als zodanig bewaard worden. Het is dan ook verstandig een aparte nummering toe te passen, om de historie van de eisen en de toewijzing aan functies en objecten apart vast te leggen, zodat op elk moment nagegaan kan worden wanneer welke eis, functie, object is vervallen, toegevoegd of gewijzigd, waarom en door wie. Omdat de relaties tussen de eisen ook vastgelegd worden, is na te gaan welke andere eisen hierbij betrokken zijn.
Voorbeeld wijzigingenstructuur onderdoorgang Nootdorp
Tijdens de eerste stap van het praktijkvoorbeeld moesten de eerste wijzigingen al worden doorgevoerd. Door dit bij te houden, blijven de eisen gewoon bestaan maar worden deze niet meer getoond. In tabel 8 is het wij zigingsbeheer weergegeven door vast te leggen welke eis uit welke informatiebron wanneer op welke wijze gewijzigd is. Eventueel kan aangevuld worden wie wanneer de wijziging heeft ingediend en goedgekeurd.
[ link ]