Modelleringmethodieken voor softwareontwikkeling zijn tegenwoordig gemeengoed maar het wordt steeds duidelijker dat ook de fase daarvoor, het opstellen van de gebruikerseisen, niet vanzelfsprekend is. De belangstelling voor het beheer van eisen en behoeften is dan ook sterk groeiend, reden om te praten met een expert op dat gebied: Ken Jackson.
Eind april was Ken Jackson een paar dagen in Rotterdam. Een tengere man met grijzende slapen kijkt een ogenblik aarzelend rond in de lobby van Hotel Inntel, maar dan valt zijn blik op de verslaggever. Een echte Engelsman, denk ik, als hij mij de hand schudt. Jackson woont op het ogenblik in Leicester waar hij ook een gasthoogleraarschap vervult. Hij is net terug van een korte wandelvakantie in het Lake District.
Professor Ken Jackson is medeoprichter van het Ieee Technical Committee on the Engineering of Computer based Systems en van het UK Chapter van de International Council on Systems Engineering (Incose). Hij is coauteur van het boek Systems Engineering – Coping with Complexity en consulent bij QSS (Quality Systems and Software).
Op dit moment houdt U zich vooral bezig met gebruikerseisen. Hoe bent U geïnteresseerd geraakt in systeemontwikkeling?
Al vanaf 1965 raakte ik als elektrotechnisch ingenieur betrokken bij software/hardware-wisselwerkingen en systeemintegratie in militaire systemen. In de loop der tijd werkte ik bij het Royal Radar Establishment en later bij Dera, de Defence Evaluation Research Agency. In een luchtverdedigingssysteem moesten zo’n vijfentwintig computers samenwerken; wij bouwden daar een bedrijfssysteem voor. In het begin van de jaren negentig kwam ik via een Esprit-programma in contact met Richard Stevens die als beoordelaar van ons project optrad. Richard werkte in 1993 voor de European Space Agency (ESA) en liep rond met plannen om zijn ideeën in een eigen bedrijf te realiseren. De ESA standaard PSS05 is wat betreft eisenbeheer een duidelijke inspiratie geweest voor de QSS-tool Doors.
Zelf was ik in de loop der jaren tot de conclusie gekomen dat het sequentiële ontwikkelingsmodel ernstig te kort schiet.
In welk opzicht?
Systeemontwikkeling omvat meerdere lagen die ook met elkaar onderhandelen. Het is te vergelijken met projectontwikkeling waarbij je verschillende aannemers hebt die elk weer onderaannemers hebben, enzovoort. Systeemontwikkeling kent ook parallelliteit en samenwerking en er zijn beslissingsmomenten. Inschatting en beheersing van risico’s vormt een heel belangrijk aspect.
Het boek ‘Systems engineering – coping with complexity’ besteedt ook aandacht aan projectbeheer.
Er is een sterk verband tussen projectmanagement en systeemmanagement. De link wordt gevormd door de eisen. Die identificeren ook de risico’s. Momenteel werk ik veel aan wervings- en outsourcingsbeheer, concurrentiebeoordeling en tender–beoordelingen. Al deze processen worden aangestuurd door eisen.
Uw boek behandelt systeemontwikkeling van de grond af aan, maar systemen worden in de praktijk toch meestal ontwikkeld vanuit bestaande systemen? Liggen de eisen dan niet van het begin af aan al vast?
Het is zeker waar dat systemen bijna nooit ontworpen worden vanuit het niets en je zou zelfs kunnen zeggen dat elk systeem zodra het werkt al een legacy-systeem is geworden. Denk ook aan het Engelse luchtverkeersleidingsysteem dat uiteraard moest blijven doorwerken in alle fasen van de vervanging door een nieuw systeem. Dat betekent echter alleen maar dat eisen bepaald kunnen zijn door de historie, niet dat ze overbodig zijn. Je moet ze kunnen formuleren om onderlinge verbanden te identificeren en om te kunnen toetsen.
U benadrukt het verschil tussen gebruikerseisen en systeemeisen.
Systeemeisen worden bepaald door gebruikerseisen en niet omgekeerd. De gebruikerseisen worden enkel en alleen vanuit het standpunt van de gebruiker geformuleerd. Het zijn scenario’s, eventueel met beslissingsmomenten en samenwerking, voor alle belanghebbenden (stakeholders). Het verschil is ook terug te vinden in de manier van testen. Gebruikerseisen worden gevalideerd en systeemeisen geverifieerd. Bij validatie test je of het goede systeem is gebouwd. Bij verificatie test je of het systeem goed is gebouwd.
Wie is de gebruiker?
Gebruikers zijn alle belanghebbenden. Astronomen zijn bijvoorbeeld gebruikers van de Hubble-ruimtetelescoop, hoewel er geen directe interacties plaatsvinden tussen deze gebruikers en het systeem.
Wat voor structuur moeten gebruikerseisen hebben? Zijn er basis categorieën of attributen die steeds weer terugkomen?
Je moet de structuur beperken tot wat de gebruikers kunnen begrijpen. Alleen dan bereik je wat wij de buy-in noemen, dat gebruikers aanhaken en verantwoordelijkheid nemen voor de eisen. Wij hebben bijvoorbeeld voor de invoering van digitale televisie dertig mensen in belangrijke managementfuncties bij de BBC geïnterviewd. De eisen die daaruit kwamen zijn met hen doorgesproken en beoordeeld. In één geval heeft het betreffende afdelingshoofd de eigen inbreng helemaal van de grond af aan herschreven. Maar aan het eind begreep iedereen het. Iedereen voelde zich betrokken, we hadden buy-in bereikt. In het algemeen kunnen gebruikerseisen ook het best geformuleerd worden in natuurlijke taal, zonder gebruik van diagrammen of schema’s.
Gebruikerseisen hebben dus een heel brede basis?
Gebruikerseisen zijn op zich weer afgeleid van zakelijke eisen (business requirements). Systeemontwikkeling moet de bedrijfsdoelstelling ondersteunen en zo wordt de systeemmanager ook commercieel manager. De marketingafdeling speelt bovendien vaak de rol van gebruiker bij het vaststellen van eisen, zeker als het een nieuw product betreft waar nog geen gebruikers van bestaan.
Testplannen voor gebruikerseisen kunnen opgesteld worden voordat er systeemeisen zijn?
Ja, testen gebeurt altijd vanuit de eisen. Als je van een gebruikerseis niet van te voren kunt zeggen hoe je kunt weten of je er aan voldaan hebt, dan is die eis niet geschikt.
Het resultaat van de acquisitie is een ‘user requirements document’. Ga je vervolgens daarvanuit de systeemeisen formuleren?
Het is niet zozeer een document maar een specificatie. Het verschil is dat een document op zichzelf staat, maar de essentie van eisen is nu juist dat ze verbonden zijn met andere eisen en ook met tests. Je stelt dan wel de gebruikerseisen op zonder aan systeemeisen te denken, maar het is goed mogelijk dat zo’n gebruikerseis uiteindelijk niet implementeerbaar blijkt te zijn. Juist vanuit de links kun je dergelijke ontwerpfouten goed opsporen.
Traceerbaarheid vormt de essentie van eisenbeheer. Denk maar aan gebruikerseisen zonder links naar systeemeisen of omgekeerd. Die situatie moet je dus niet hebben. Ook traceerbaarheid van attributen, beperkingen en prioriteiten is natuurlijk belangrijk.
Tools zijn hierbij dan van grote waarde?
Zeker. Een tool als Doors (Dynamic Object Oriented Requirements management Systeem) vervult feitelijk de rol van repository. Doors staat ook weer niet per se op zichzelf, maar is met andere hulpmiddelen te gebruiken. Denk ook aan voorkomende eisen vanuit kwaliteitsmodellen als CMM (Capability Maturity Model).
In Uw boek wordt een aantal praktijk toepassingen geschetst, onder meer bij Lucent, Motorola maar ook Barclays Bank. Die bedrijven hanteren niet dezelfde ontwikkelcyclus voor hun producten of software.
Dat hoeft ook niet. Als we een bedrijf adviseren, beginnen we altijd met een information architecture workshop. Het doel hiervan is om een zogenaamde navigatiekaart op te stellen die past bij de bedrijfsactiviteiten. Anderen noemen dit een levenscyclusmodel.
Systeemontwikkelaars lijken soms vage en veranderlijke termen te hanteren
Gelukkig brengt de voorgestelde Systems Engineering standaard ISO 15288 meer eenheid aan in de terminologie. Stuart Arnold, coauteur van ons boek, is ook een van de redacteuren van deze norm. Maar systeemontwikkeling is beslist nog een jonge wetenschap.
Hans van Thiel, freelance medewerker
