Zakelijke eisen, gebruikerseisen, en systeemeisen voor productiesystemen

Tijdens mij blogserie over Lean Validatie heb ik het belang van gebruikerseisen al aangehaald. Bij het definiëren van eisen waaraan productiemiddelen moeten voldoen raken veel mensen in de war met alle verschillende typen eisen. Daarbij helpt het om de eisen te categoriseren in zakelijke eisen, gebruikerseisen en systeemeisen. Alle drie dienen verschillende doelen.

Zakelijke eisen (Business requirements) beschrijven waarom de organisatie bezig is met het project. Welke voordelen verwacht de organisatie te behalen met de ontwikkeling of aanschaf van het nieuwe productiemiddel. Deze zakelijke behoeften worden afgebakend in verschillende documenten, zoals een project plan, project charter en business case. De resultaten van de analyse van bedrijfsprocessen en stakeholderanalyse activiteiten worden ook beschouwd als zakelijke behoeften. Het doel van het bedrijfsproces analyse is om te bepalen hoe het bedrijfsproces werkt. Vaak is het nodig om tekortkomingen in het bedrijfsproces te identificeren voordat je een nieuw productiemiddel introduceert. Zonder het in kaart brengen van het productieproces zal het productiemiddel er ook wel komen, maar het zal zeker niet de meest directe route zijn naar het meest geschikte projectresultaat, als je dat al bereikt. De stakeholder analyse is nodig om te bepalen wie zal worden beïnvloed door het systeem. Deze mensen moet je betrekken bij het verkrijgen van de gebruikerseisen.

We houden rekening met de volgende business eisen.

• Probleemstelling
• Project doelstellingen
• Project visie: op welke wijze denkt men het probleem te kunnen oplossen
• Project reikwijdte verklaringen
• Project voorwaarden: budget, aansluiting met bestaande voorzieningen en productieprocessen

Maar je kunt geen productiemiddel bouwen met alleen een dergelijk hoog niveau van informatie. Maar door de business eisen te koppelen aan de gebruikers- en systeemeisen wordt het projectmanagement gekoppeld aan het systeemontwerp. Ook het identificeren van project- en systeemrisico’s kan bijdragen tot het opstellen van systeemeisen.

Gebruikerseisen (User requirements), vaak ook wel aangeduid als gebruikersbehoeften, beschrijven wat de gebruiker doet met het systeem, zoals welke activiteiten de gebruikers moeten kunnen uitvoeren. Behoeften van de gebruikers zijn over het algemeen vastgelegd in een User Requirements Specification (URS).

We houden rekening met de volgende gebruikerseisen.

• Een proces flow diagram
• Beslissingsmomenten die door het systeem worden ondersteund
• De (minimale) kwaliteitsspecificaties van de halffabricaten of eindproducten die met het productiemiddel worden voortgebracht.

Het opstellen van de gebruikersbehoeften is vaak één van de moeilijkste stappen in het project. Dit komt omdat de gebruikers vaak niet in staat zijn om hun behoeften onder woorden te brengen en vaak niet echt weten wat ze willen. De informatie die zij verstrekken kan ook onvolledig, onjuist en zelf-tegenstrijdig zijn. Daarnaast kunnen verschillende gebruikers tegenstrijdige behoeftes hebben. Vandaar dat niet de gebruiker, maar een verantwoordelijke vanuit het projectteam de gebruikerseisen opstelt. Daarbij moeten de wensen en behoeftes wel grondig worden geanalyseerd met de verantwoordelijkheid volledig te begrijpen wat de klant wil. De opgestelde URS moet uiteindelijk worden afgetekend door de gebruiker als bevestiging dat het de gebruikersbehoefte correct weergeeft. De URS wordt gebruikt als de primaire input voor het maken van de systeemeisen.

Testplannen die worden opgesteld voor het valideren of het systeem aan de gebruikerseisen voldoen kunnen al worden opgesteld voordat de systeemeisen zijn vastgelegd. Dat is ook een goede oefening of de gebruikerseisen voldoende en juist zijn opgesteld. 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.

Systeemeisen (System requirements) zijn de bouwstenen die engineers gebruiken om het systeem te ontwikkelen en te bouwen. Dit zijn verklaringen die beschrijven wat het systeem zal doen. Systeemeisen worden bepaald door gebruikerseisen en niet omgekeerd.

Systeemeisen zijn een gedetailleerde uitwerking van de gebruikerseisen. Systeemeisen zijn altijd toegewezen aan de gebruikerseisen, zodat de grondslag van de eis duidelijk is. De essentie van systeemeisen is dat ze verbonden zijn met de bovenliggen gebruikers eisen en zakelijke eisen. Juist vanuit de links kun je ontwerpfouten goed opsporen. De traceerbaarheid vormt de essentie van eisenbeheer. Ook de traceerbaarheid naar de testen die worden uitgevoerd om vast te stellen of aan de eisen is voldaan. Gebruikerseisen worden gevalideerd (PQ) en systeemeisen geverifieerd (commissioning) of gekwalificeerd (IQ/OQ). Bij validatie test je of het goede systeem is gebouwd. Bij verificatie test je of het systeem goed is gebouwd.

Systeemeisen worden geclassificeerd als functionele of aanvullende eisen. Waar gebruikerseisen het gebruik van het systeem beschrijven, beschrijven de functionele systeemeisen het gedrag van het systeem. Een functionele eis geeft aan wat het systeem moet kunnen om aan de gebruikersbehoefte te voldoen. Bijvoorbeeld: het systeem zal de temperatuur regelen en monitoren om het temperatuurafhankelijke proces te kunnen beheersen. Gekoppeld aan de functionele eisen zijn kwaliteitseisen: Kwaliteitseisen geven aan hoe goed het systeem zijn functies moet vervullen. Vervult of vervangt het systeem een al bestaand productieproces dan zijn gegevens uit product- en procesvalidaties en proces monitoring een essentiële bron van kwaliteitseisen.

Voorbeelden van functionele eisen zijn:

• De kritische procesvariabelen die met het systeem moeten worden beheerst
• Het minimaal noodzakelijke operationele bereik van de procesvariabelen
• De nauwkeurigheid waarmee de procesvariabelen kunnen worden geregeld
• De kritische controle punten (CPP)
• De nauwkeurigheid waarmee de controlepunten kunnen worden gemeten
• De minimale productiecapaciteit
• De informatie die door het systeem wordt gegenereerd

Aanvullende of niet-functionele eisen specificeren de eigenschappen van het systeem die niet direct bijdragen aan het gebruikersdoel van het systeem. Voorbeelden hiervan zijn de machineveiligheidseisen, die de gebruiker in staat stellen het systeem veilig te gebruiken, maar die niet een beter productieproces opleveren. Ik geef de voorkeur aan de term aanvullende eisen in plaats van niet-functionele eisen, omdat de aanvullende eisen wel degelijk kunnen resulteren in functionele onderdelen van het systeem (bijvoorbeeld veiligheidskleppen).

De lijst hieronder toont de verschillende soorten aanvullende eisen.

• Compliance: overeenstemming met wettelijke eisen (o.a. Europese machinerichtlijn, 21CFR part11), richtlijnen (bv EHEDG), normen (ISO, ASTM, DIN, IEC, etc.) en engineering standaarden van de gebruiker
• Milieu en ARBO eisen
• Onderhoudbaarheid en reinigbaarheid
• Garantiebepalingen en support contract eisen
• Duurzaamheid
• Betrouwbaarheid: bijvoorbeeld mean time between failures (MTBF)
• Gebruikersgemak en operabiliteit
• Overall Equipment Effectiveness (OEE)
• Inbreng van de leverancier bij de inbedrijfstelling van het productiemiddel
• Inbreng van de leverancier in training van gebruikers en eventueel organisatorische veranderingsprocessen die noodzakelijk zijn
• Systeem documentatie die door de leverancier moet worden meegeleverd

De functionele en aanvullende eisen worden gedocumenteerd in de system requirements specification (SRS). De SRS wordt door de ontwerpers van het systeem gebruikt om de functionele en technische specificaties van het systeem op te stellen. Eisen kunnen tijdens het project wijzigen als gevolg van inzichten die tijdens het ontwikkeltraject worden opgedaan. Je stelt de gebruikerseisen op zonder aan systeemeisen te denken, maar het is goed mogelijk dat zo’n gebruikerseis uiteindelijk niet implementeerbaar blijkt te zijn. Eisen blijken niet alleen harde eisen zijn, maar ook wensen en mogelijkheden met betrekking tot een te implementeren systeem. Het kan zinvol zijn om dit als prioriteit bij elke eis mee te geven. Het is belangrijk om de requirement specificaties te wijzigen naar de actuele inzichten, omdat ze de basis vormen voor alle kwalificatie activiteiten (ontwerpkwalificatie, commissioning en procesvalidate).