Syftet med kravspecifikationsfasen i EN 50126 är definierat i fyra delar:
- Att specificera de samlade RAMS-kraven
- Att specificera processen och kriterierna för hur bevisning av kravuppfyllnad av RAMS-kraven ska genomföras
- Att tillhandahålla en komplett kravmängd för efterföljande livscykelfaser
- Att specificera de krav som behövs för uppföljning av drift och underhåll i driftsfasen (här hänvisar man till en process som ska definieras i säkerhetsplanen, som vi inte berör närmare i denna blogg)
Kraven man ställer på vad ”de samlade RAMS-kraven” ska innehålla är omfattande; funktionskrav, prestandakrav, säkerhetsmål för säkerhetsfunktionerna, underhållskrav, gränsytekrav, krav från användningsmiljön och driftprofilen, etc. Det är tydligt att detta är långt ifrån rena RAMS-krav, utan det är systemets kompletta kravspecifikation som avses. Och detta stämmer ju bra med vad vi noterat tidigare – att det är hela systemet som befinner sig i en viss livscykelfas. Därigenom är det också olyckligt att man använder benämningen RAMS-krav – ”systemkrav” hade varit mycket bättre!
Om vi följer stegen i EN 50126 har vi hittills i konceptfasen analyserat problemdomänen genom att ta fram konceptbeskrivningar, ex.vis underhållskonceptet och RAM-mål i form av krav på operationell tillgänglighet. Vi har också börjat titta på lösningsdomänen genom att påbörja framtagandet av systemdefinitionen och gjort en initial riskanalys för att identifiera ytterligare krav ur ett säkerhetsperspektiv. I riskanalys-fasen har vi också tittat på tillgänglighetskrav för de olika funktionerna som definierats i systemdefinitionen. Nu ska lösningen bli mer detaljerad i form av formella krav.
Låt oss ta ett steg tillbaka och titta på den RAM-process som presenterades i ett tidigare blogginlägg:
Översiktlig RAM-process
I bilden på RAM-processen finns såväl kundkrav som systemkrav. I en typisk kund-leverantörsrelation finns båda dessa kravmängder och, som jag ser det, hör båda hemma i kravspecifikationsfasen i EN 50126. Standarden tar dock ingen hänsyn till att dessa två perspektiv finns. Men högst sannolikt är inte kundkravspecifikationen så detaljerad och komplett att den kan användas som underlag för realisering av systemet. Och därför kan inte en leverantör komma undan sin roll i att ta fram den systemkravspecifikation som denne ska använda för att realisera systemet.
EN 50126 ställer också krav på att en valideringsrapport ska tas fram i denna fas. Det står att valideringen ska täcka fas 1-4 och handlar om att validera kraven på systemet och processen för att ta fram dem. Validering svarar ju på frågan om systemet man byggt möter kundens behov (”har vi byggt rätt system?”) och kravvalidering handlar, som EN 50126 skriver, om att förvissa sig om att systemkraven har blivit ordentligt specificerade.1 Valideringsrapporten som tas fram ska både titta på processen som har använts för att ta fram kraven (fas 1-4) men också på kraven i sig; den ska innehålla ”confirmation that all system requirements (including RAMS, functional, and external legal requirements) are adequately analysed and specified in order to allow the system under consideration to serve the intended use”.2
Kravvalidering svarar alltså på frågan “om vi bygger ett system baserat på dessa krav, får vi då ett system som möter kundens behov?”.
EN 50126 beskriver att ansvaret för att genomföra kravvalideringen generellt sett är kundens ansvar.3 Detta är vanskligt för det kan ge intrycket av att leverantören inte har någon roll i framtagningen av systemkraven eller i kravvalideringen. I stället bör man se det som att kravvalideringen är en avstämningspunkt mellan kund och leverantör när kunden bekräftar att det system som definieras av systemkravspecifikationen möter kundens behov. Kundens ansvar är alltså att godkänna systemkravspecifikationen som leverantören har tagit fram!
[1] EN 50126-1:2017, kap. 6.7.3
[2] EN 50126-1:2017, kap. 7.5.4
[3] EN 50126-1:2017, kap. 6.7.3