Guide til udfyldelse af krav i OS2kravmotor

Overordnet

Kravet skal formuleres så det kort og præcist beskriver det krav som stilles til leverandøren. Dvs. at kravet skal falde ind i præcis én kravkategori, og ikke kunne opsplittes i flere selvstændige krav.

Retningslinjer

• Konsistens. Kravteksten skal bruge betegnelsen "kommunen" om den indkøbende kommune, og ikke kommunens navn og/eller andre betegnelser som "kunden", "indkøberen" eller lignende.
• Konsistens. Kravteksten skal bruge betegnelsen "løsningen" om det it-system der skal indkøbes.
• Konsistens. Samme ord for tværgående begreber bør bruges i alle krav, fx anvendes GDPR som angivelse for eudatabeskyttelsesforordningen. Det anbefales, at man gør sig bekendt med begreber, der anvendes i eksisterende krav.
• Ikke-overlappende. Krav bør så vidt muligt ikke overlappe hinanden.
• System-uafhængigt. Kravteksten skal ikke referere til det ønskede system ved navn, eller til andre systemer ved navn med mindre, der er tale om nationale løsninger. Fx angives 'ESDH-system' i stedet for 'Formpipe Acadre', og 'Kommunens EOJ løsning' i stedet for 'KMD Nexus'. Dette sikrer, at kravteksten kan genbruges af andre kommuner. Nationale løsninger som patientindeks, fælles medicinkort, DFDG m.m. angives ved navns nævnelse.
• Vurderingsmuligt. Kravet skal formuleres, så leverandørens besvarelse kan vurderes, dvs. kravet skal så vidt muligt formuleres, så man efterfølgende kan holde leverandørens besvarelse op mod kravet.

Form

Formuleringen af kravteksten bør følge nedenstående opbygning

• Krav. Kort kravtekst der forklarer, hvad vi ønsker.
• Rationale. Kort tekst, der angiver vores rationale for at stille kravet.
• Konsekvens ved afgivelse. Den konsekvens det vil have for os, hvis kravet ikke indfries.

Eksempel

Løsningen skal understøtte fødereret adgangsstyring.

Den fælleskommunale rammearkitekturs byggeblokke for sikkerhed baserer sig på fødereret adgangsstyring, og KOMBITs støttesystemer til samme, er en konkret implementation af denne strategi.

Løsningen skal støtte op om denne strategi, ved at understøtte, at brugere oprettes og tildeles rettigheder i kommunens centrale rettighedsstyringssystem, eller ved at rettigheder tildeles via KOMBITs støttesystemer.

Løsningen må derfor ikke kræve, at brugere skal oprettes manuelt i løsningen, eller at tildelingen af rettigheder til brugere skal foregå inde i løsningen. Løsningen må dog gerne tilbyde funktionalitet til intern brugerstyring, så længe den også understøtter fødereret brugerstyring.

Løsningen skal understøtte SAML 2.0 eller WS-Federation som føderationsteknologi, da dette er kompatibelt med den brugerstyringsløsning, som kommunen anvender, samt den teknologi som KOMBITs støttesystemer anvender.

Hvis kravet ikke opfyldes, vil det introducere unødige arbejdsgange, og øge omkostningerne til brugerstyring i kommunen.