Skip to content

Hoe maak je een User Requirement Specification voor operationele systemen

13 maart 2015

validatie

Gebruikerseisen moeten het uitgangspunt zijn van elk project. Alle activiteiten staan ten dienst van het vervullen van de wensen (eisen) van degene die het resultaat van het project zal gaan gebruiken, of die hierbij een belang heeft (de stakeholder).Tijd besteed aan het ontwikkelen van solide gebruikerseisen zal het project enorm helpen. Het is zinvol bestede tijd, die je tijdens de ontwikkel- en testfase van het project dubbel en dwars zult terugverdienen. In de praktijk wordt deze tijd veelal niet genomen en constateert de validatie engineer in de testfase dat er geen gebruikerseisen zijn die hij kan hanteren voor het opstellen van de protocollen.

Hoe moeilijk kan het zijn om een document op te stellen waarin staat wat je precies van een systeem of een apparaat verwacht? Nou, dat blijkt toch best ingewikkeld. Vaak weten gebruikers niet exact wat ze willen, omdat een voorstellingsvermogen ontbreekt. Gebruikers kunnen vaak slecht hun eisen precies formuleren. Ze kunnen echter wel goede voorbeelden geven van gewenst gedrag van een systeem. Deze voorbeelden worden use-cases genoemd. Soms is het ook lastig in te zien hoe een bepaald probleem systemisch ontrafeld kan worden. Een prototype geeft dan veel nieuwe informatie en inzicht. Ook kan vooraf niet altijd voldoende beoordeeld worden hoe afwegingen tussen gebuikerseisen uitpakken. Als men dit onderkent, is er geen probleem. In de initiële specificatie van de gebruikerseisen kan worden aangegeven waar de onzekerheden zitten en waar de specificatie dus zal worden bijgewerkt naarmate er meer informatie beschikbaar is.

Gebruikerseisen worden vaak opgesteld door degenen die verantwoordelijk zijn voor de ontwikkeling van het systeem of het apparaat. Maar zij zijn niet de gebruiker van het systeem. Informatie voor de gebruikerseisen wordt gehaald uit de opdracht voor het project. Maar de opdracht is vaak te vaag en de daadwerkelijke gebruikers zijn onvoldoende betrokken bij de opdrachtformulering. Wat men verwacht van het systeem wordt ook nog gecompliceerd door het feit dat er verschillende disciplines bij betrokken zijn met conflicterende eisen, of zelfs een onderlinge machtsstrijd. Op zich is er geen bezwaar dat projectteamleden als auteur van de gebruikerseisen optreden, maar zij moeten de input vragen van de gebruikers en andere belanghebbenden (engineers, (interne) klanten, technische dienst, materiedeskundigen, et cetera) en een standpunt durven in te nemen in geval van tegenstrijdige belangen. Ook moet een realistische capaciteitsinschatting worden gemaakt: het schaap met de vijf poten is onhaalbaar of onbetaalbaar. Gebruik de gebruikerseisen voor het vergelijken en selecteren van leveranciers. Documenteer de voors en tegens van elke leverancier. De vragen en opmerkingen van leveranciers tijdens de offertefase leveren nieuwe informatie. Aarzel dan niet deze op te nemen in de gebruikerseisen.

Tijdens de requirements engineering fase worden de eisen van gebruikers en andere belanghebbenden (“stakeholders”) zorgvuldig geïdentificeerd en gedocumenteerd. De gebruikerseisen moeten duidelijk en nauwkeurig definiëren wat het systeem moet doen. Welke toegevoegde waarde moet door het systeem worden geleverd? Welk probleem wordt er met het systeem opgelost? Deze eisen betreffen zowel de functionaliteit alsook de kwaliteit: hoe snel moet het zijn? Hoe betrouwbaar, reproduceerbaar, herleidbaar, et cetera, moet het systeem functioneren? Requirements engineering is een constructief proces van analyseren, documenteren en toetsen van de verzamelde kennis van de gebruikers en andere belanghebbenden. Het bestaat uit drie fases:

  • Elicitatie: het begrijpen van het probleem waarvoor een oplossing wordt gezocht. Algemene kennis is vereist om te waarborgen dat de oplossing past bij de organisatiedoelen en cultuur. Proceskennis is nodig om de belangrijkste functionele eisen te identificeren.
  • Specificatie: het beschrijven van het probleem en het vaststellen van de gebruikerseisen.
  • Validatie en verificatie: het onderling eens worden over het probleem en het vaststellen dat de juiste eisen zijn vastgelegd (validatie), en dat deze eisen juist zijn vastgelegd (verificatie). Het reviewen en goedkeuren van het document is een bewijs van de betrokkenheid van de gebruikers bij deze fase.

Vanzelfsprekend vindt er iteratie en terugkoppeling plaats tussen deze processen. En, zoals gezegd, gebruikerseisen zijn niet in beton gegoten. Al gaande het project wordt men wijzer. Men krijgt een duidelijker beeld van het probleem waarvoor het systeem een oplossing moet bieden (elicatie). Ook eventuele risico’s komen aan het licht, waardoor diepgaande beperkingen en voorwaarden boven tafel komen (specificatie). Ook de prioriteitstelling wordt minder subjectief (validatie). Al deze aspecten leiden tot veranderingen in de gebruikerseisen. Deze veranderingen moeten worden beheerst (verificatie). Let wel: De oorspronkelijke scope moet worden gehandhaafd; een uitbreiding van het toepassingsgebied moet alleen mogelijk zijn door middel van een formeel change control proces.

Er zijn nogal wat technieken voor het vastleggen van gebruikerseisen, variërend van informeel (natuurlijke taal en plaatjes) tot zeer formeel (systemisch met tabellen, wiskundig met berekeningen, modelmatig met diagrammen). De informele technieken leiden eerder tot onduidelijkheid on onvolledigheid, daar waar formele technieken niet voor iedereen begrijpelijk zijn, omdat het verhaal (het probleem) niet duidelijk wordt. Een combinatie van technieken leidt dus tot het beste resultaat.

De specificatie van de gebruikerseisen moet aan nogal wat eisen voldoen:

  • Gebruikerseisen moeten beknopt, maar ook leesbaar en begrijpelijk zijn. Diverse belanghebbenden baseren hier immers hun beslissingen op. Formuleer SMART: Specifiek, Meetbaar, Haalbaar, Realistisch, Toetsbaar.
  • Gebruikerseisen moeten voor maar één uitleg vatbaar zijn. Gebruikerseisen moeten maar op één manier kunnen worden geïnterpreteerd, en dat is per definitie lastig bij natuurlijke taal.
  • Gebruikerseisen moeten volledig zijn. Alle belangrijke zaken met betrekking tot functionaliteit, prestaties, e.d., moeten zijn gedocumenteerd. Voor alle functies moet zowel worden aangegeven wat het systeem moet doen bij juiste invoer, en hoe het moet reageren bij onjuiste invoer. Eventuele beperkingen moeten worden gedefinieerd, zodat de ontwerpruimte vooraf bekend is.
  • Gebruikerseisen moeten correct zijn. Zij moeten overeenstemmen met geaccepteerde normen en standaarden. Deze komen voort uit wet- en regelgeving, internationale normen (ISO, IEEE, ASTM, etc) of de engineering standaarden van het bedrijf.
  • Gebruikerseisen moeten (intern) consistent zijn. Het gebruik van verschillende termen voor één en hetzelfde kan leiden tot tegenstrijdigheden.
  • Gebruikerseisen moeten worden geordend qua belang of prioriteit. Meestal zijn sommige eisen belangrijker dan andere. Vaak is een eenvoudige ordening, als `essentieel’, `belangrijk’ en `handig’ al voldoende. (of MoSCoW) Dit soort informatie nodigt gebruikers uit beter over de haalbaarheid van hun eisen na te denken. Het biedt ontwikkelaars de mogelijkheid hun aandacht beter te richten.
  • Gebruikerseisen moeten getest kunnen worden. Het moet uiteindelijk mogelijk zijn om te bepalen of het systeem aan de eisen voldoet. Zinsneden als `het systeem moet gebruikersvriendelijk’ zijn, zijn niet te testen. Ook het gebruik van vage termen die niet zijn te kwantificeren (‘vele’, ‘vaak’, ‘meestal’), kunnen beter worden voorkomen. Maar ook termen als ‘elke’, ‘alle’ brengen risico’s met zich mee.
  • Gebruikerseisen moeten traceerbaar zijn. De oorsprong en rationale van elke requirement moet terug te vinden zijn.
  • Gebruikerseisen moeten slechts één voorwaarde bevatten. Vermijd ‘en’ of ‘of’ in de specificatie van gebruikerseisen. Vermijd ook uitsluitingen: ‘tenzij’, ‘behalve’, ‘indien nodig’. Dit zal het traceren van de eis gedurende de ontwerp en testfase vereenvoudigen. Individuele eisen moeten traceerbaar blijven gedurende de levenscyclus van het systeem.

De gebruikerseisen hebben bij voorkeur het volgende format

  • Het type gebruiker of de actor die de eis stelt:
    “De operator kan…”
  • De functionaliteit: “… het systeem bedienen …”
  • Controleerbare criteria: “… met behulp van een bedieningspanneel”.

De gebruikerseisen omvatten typisch, maar zijn niet beperkt tot:

  • Operationele eisen
  • Functionele eisen
  • Niet functionele eisen (betrouwbaarheid, beveiliging, beschikbaarheidseisen veiligheidseisen, milieueisen, onderhoudseisen)
  • Technische eisen.
  • Informatieeisen (creëren, wijzigen, opslaan, gebruiken, rapporteren van data)
  • Systeem afbakening en interface-eisen zoals invoer (grondstoffen, hulpmiddelen, informatie), uitvoer (product, informatie), voorzieningen (gas, water, electra).
  • Wettelijke eisen.
  • Beperkingen en randvoorwaarden.
  • Levenscyclus eisen.

Lees ook mij voorgaande blog over zakelijke eisen, gebruikerseisen en systeemeisen om een begrip te krijgen van de inhoud van de URS

Advertenties

Geef een reactie

Vul je gegevens in of klik op een icoon om in te loggen.

WordPress.com logo

Je reageert onder je WordPress.com account. Log uit / Bijwerken )

Twitter-afbeelding

Je reageert onder je Twitter account. Log uit / Bijwerken )

Facebook foto

Je reageert onder je Facebook account. Log uit / Bijwerken )

Google+ photo

Je reageert onder je Google+ account. Log uit / Bijwerken )

Verbinden met %s

%d bloggers liken dit: