HVORDAN ARBEJDES DER MED NON-FUNKTIONELLE KRAV HOS KOMBITv/ Lasse Geisler, ArkitektKit@ og OS2 temadag om Den gode IT-anskaffelse- 27/6 2019

HVEM ER JEG?

• Lasse Geisler• Ansat hos KOMBIT d. 1/11 2016 (2 ¾ år)• Primært arbejdet med Valgprojektet,

men siden februar arbejdet på Fælles bibliotekssystemer og Fælles biblioteksinfrastruktur

• Tidligere arkitekturerfaring fra Coop, Leo PHARMA, DSB

"Jeg mener, at værdien af it-arkitektur først er opnået,

når det er implementeret. Derfor er kommunikation det

vigtigste redskab for en arkitekt."

KOMBIT

KOMBIT er kommunernes it-fællesskab – vi skaber konkurrence i det kommunale it-marked.

Vores primære opgave er at indkøbe IT-Systemer på vegne af (alle) kommuner.

Monopolbruddet skal skabe konkurrence og åbne markedet for flere leverandører.

NON-FUNCTIONAL REQUIREMENTS

Fra Wikipedia:In systems engineering and requirements engineering, a non-functional requirement(NFR) is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors. They are contrasted with functionalrequirements that define specific behavior or functions. The plan for implementingfunctional requirements is detailed in the system design. The plan for implementingnon-functional requirements is detailed in the system architecture, because they areusually architecturally significant requirements.

Ud fra denne definition, giver det god mening at KOMBIT har valgt at placere ansvaret for de non funktionelle krav hos arkitekterne.

VIGTIG VIDEN: i forhold til KOMBITs udbudsmaterialer

En stor del af det, der generelt betragtes som non-funktionelle krav varetages af driftskontrakten, der indgår som en delmængde af den samlede kontrakt i forbindelse med udbud.

Driftskontrakten beskæftiger sig med SLA, oppetider, drift af miljøer og så videre. Altså alt efter at systemet er ”overdraget”.

Derudover er der i udbudsmaterialet bilag, der definerer krav til:

• Uddannelse• Implementering• Test• Dokumentation

EKSEMPEL: Valgs udbudsmaterialeUdbudsmateriale kompleks:

• 0 Definitioner på tværs af materialet• 1 Hovedkontrakt inklusiv tidsplan• 2 Leverancebeskrivelse inklusiv funktionelle og

non funktionelle krav (25 bilag)• 3 Ændringshåndteringsbeskrivelse• 4 Dokumentationsbeskrivelse• 5 Priser og betalingsplan• 6 Intern test og prøver (8 bilag)• 7 Driftskontrakt (40 bilag)• 8 Udviklingsmetode og samarbejdsorganisation• 9 KOMBITs deltagelse• 10 Licensbetingelser• 11 Optioner• 12 Uddannelse• 13 Udrulning• 14 Koordinering med Print og Distribution af

valgkort• 15 Leverandørens opgaver i forbindelse med VALG

I alt 103 dokumenter

VALG KRAVSPECIFIKATIONEN: Bilag 2.1

FACTS:Ca. 250 sider, ca. 310 krav / heraf 7 mindstekrav

Funktionelt: 130 sider og ca. 130 kravNon-funktionelt: 120 sider og ca. 180 krav

Afsnit i det non-funktionelle:• Arkitektur• Integrationer• Print• Brugeroplevelse• Lovkrav• Sikkerhed• Logning• Volumen-tal

Eksempel på krav

Desuden er der i kravspecifikationen, eventuelt forklarende tekst rundt om. Denne tekst er lige så bindende som selve kravet, men kan være sværere at verificere.

LEVERANDØRERNES BESVARELSE: Bilag 2.2.A

Bilag 2.2.AGruppe 2A: Arkitektur [Tilbudsgiver bedes redegøre for, hvorledes krav i afsnit 6.1, med undtagelse af krav i afsnit 6.1.3.1 (Valglistemodulet), i bilag 2.1 imødekommes. Tilbudsgiver bedes redegøre for:Tilbudsgivers arkitektur- og teknologivalg;afvigelser fra de fælleskommunale arkitekturprincipper samt en begrundelse herfor; Systemets arkitektur til håndtering af adgangsstyring, herunder sammenhæng med støttesystemet Adgangsstyring samt kommunernes muligheder for at administrere dette (støttesystemet Administration). Tilbudsgiver bedes i denne sammenhæng også redegøre for, hvorledes man sammen med KOMBIT vil afklare de nødvendige roller, rettigheder og dataafgrænsninger;hvordan det sikres, at Systemet kan afvikles på flest mulige nuværende og fremtidige browser-løsninger;hvilken funktionalitet der implementeres via standardmoduler, hvilke der implementeres via standardmoduler, der skal tilpasses, og hvilken funktionalitet der skal nyudvikles.

KOMBIT lægger i vurderingen af besvarelsen i særlig høj grad vægt på, at

arkitektur- og teknologivalg for Systemet understøtter mulighed for smidig og omkostningseffektiv overdragelse af Systemet og data til tredjepart;arkitektur- og teknologivalg for Systemet understøtter mulighed for omkostningseffektiv videreudvikling af Systemet (inklusiv Integrationer til og fra Systemet);Systemets modulopdeling følger fælleskommunale arkitekturprincipper og dermed løst koblede komponenter, med klar ansvarsfordeling; der er så få afvigelser som muligt fra de fælleskommunale arkitekturprincipper, og at eventuelle afvigelser vurderes velbegrundede;Systemet i størst muligt omfang kan anvendes uafhængigt af integrationer, og at reetablering af data fra integrationer sker effektivt og sikkert;Systemet kan håndtere ændringer i love og regler omkostningseffektivt;Systemet kan afvikles på alle eller de mest udbredte browser-løsninger, og at Systemet er fremtidssikret i forhold til fremtidige browser-løsninger, herunder opdateringer til disse;Systemets håndtering af Brugere gennem adgangsstyring er let og fleksibel for kommunerne at administrere og styre.

LEVERANDØRERNES BESVARELSE: Bilag 2.2.B

MINDSTEKRAV

FORDELE:1. Behøver ikke at bruge energi på at sikre de er med2. Behøver ikke at afsætte tildelingskriterier til dem3. Sikker på ikke at skulle godkende tilbud, der ikke opfylder kravet

ULEMPER:1. Såfremt en leverandør kommer til at skrive, at de ikke kan opfylde kravet, eller vil

opfylde behovet på anden måde, så er det ikke muligt at tage dem med i vurderingen

2. Hvis man, efter valg af leverandør, når frem til at kravet alligevel ikke behøver at blive leveret, så er det ikke muligt i forhold til EU lovgivning

TEST AF KRAV

Husk at vurdere testbarheden af et krav

• Overambitiøse krav: Systemet skal efter endt implementation optages i guiness world of record som det bedste valgsystem

• Krav udenfor leverandørens indflydelse: 2 dage efter udskrivning af valget skal alle have modtaget deres valgkort

• Skriv i stedet: 4 timer efter modtagelse af stemmeberettigede i CSV fil, skal PDF med valgkort være leveret til printleverandøren via integration valg-01

• Krav der ikke kan verificeres via test men via dokumentation: Systemet skal implementeres med et højt sikkerhedsniveau i enhver henseende, herunder i løsningsdesign, adgangskontrol, netværk, fysisk sikkerhed, procedurer og administration

• Krav der ikke kan testes i forbindelse med overdragelse: • Systemet skal implementeres i henhold til national og international ”good practice” for sikring af it-systemer• Systemet skal være effektivt og intuitivt at anvende, så det gør Brugeren i stand til hurtigt og korrekt at

gennemføre sine arbejdsopgaver uden brug af hjælp, og minimerer risikoen for fejl.

EKSEMPEL: standarder / lovkrav man med fordel kan inkludere

Krav VALG-R405 Tilgængelighed Kategori: K Type: Ikke-funktionelt Beskrivelse: Webbaserede brugergrænseflader skal opfylde tilgængelighedskravene

under Web Content Accessibility Guidelines (WCAG) 2.0, niveau 2, AA eller nyere.

Forretningsbehov: FB-03 Brugervenlig it-understøttelse

Krav VALG-R410 Systemet skal overholde gældende lovgivning Kategori: MK Type: Ikke-funktionelt Beskrivelse: Systemet skal understøtte, at Brugerne ved anvendelse af Systemet

overholder gældende relevant lovgivning, herunder den domænespecifikke lovgivning som anført i afsnit 6.5.1. Reglerne, udledt af denne lovgivning er nærmere beskrevet i bilag 2.1.C. Det er KOMBITs ansvar at fortolke lovgivningen jf. bilag 8.

Forretningsbehov: FB-01 Effektiv og lovmedholdelig opgaveløsning

Krav VALG-R411 Overholdelse af lovkrav vedrørende personoplysninger Kategori: MK Type: Ikke-funktionelt Beskrivelse: Systemet skal understøtte, at Brugere kan behandle personoplysninger i

overensstemmelse med Databeskyttelsesforordningen med efterfølgende ændringer (General Data Protection Regulation 679/2016). Datatilsynets praksis omkring behandling af personoplysninger skal følges, og data skal behandles i overensstemmelse med god databehandlingsskik.

Forretningsbehov: FB-01 Effektiv og lovmedholdelig opgaveløsning

Krav VALG-R412 Understøttelse af Sikkerhedsbekendtgørelsens §19 Kategori: MK Type: Ikke-funktionelt Beskrivelse: Systemet skal kunne logge alle anvendelser af persondataoplysninger i

brugergrænsefladen i henhold til Sikkerhedsbekendtgørelsen §19. Forretningsbehov: FB-01 Effektiv og lovmedholdelig opgaveløsning

EKSEMPEL: standarder / lovkrav man med fordel kan inkludere

Krav VALG-R414 Cookielovgivning Kategori: MK Type: Ikke-funktionelt Beskrivelse: Systemet skal ifm. hjemmesider (Valginformation, præsentation af data og

Option 1: Selvbetjent kandidatanmeldelse) overholde Bekendtgørelse om krav til information og samtykke ved lagring af eller adgang til oplysninger i slutbrugeres terminaludstyr (Cookielovgivningen).

Forretningsbehov: FB-01 Effektiv og lovmedholdelig opgaveløsning Krav VALG-R415 Overholdelse af Arkivloven

Kategori: MK Type: Ikke-funktionelt Beskrivelse: Systemet er arkivpligtigt og skal derfor kunne danne en samlet

arkiveringsversion af data, som skal afleveres til Rigsarkivet. Arkiveringsversionen skal følge de til enhver tid gældende retningslinjer herfor. De nuværende retningslinjer følger af bilag 2-8 i linkede bekendtgørelse: https://www.retsinformation.dk/Forms/R0710.aspx?id=132898. Leverandøren skal sikre, at der afleveres data fra Systemet til Rigsarkivet jf. Snitflade VALG-20. Se afsnit 6.2.1.8. Leverandøren skal, i samarbejde med KOMBIT, i Etape 2 i dialog med Rigsarkivet, fastlægge hvilke data på tabelniveau, som er arkivpligtige i Systemet.

Forretningsbehov: FB-01 Effektiv og lovmedholdelig opgaveløsning

EKSEMPEL: standarder / lovkrav man med fordel kan inkludere

DEN PERFEKTE KRAVSPECIFIKATION

Personligt mener jeg ikke det er muligt at skrive en kravspecifikation der rammer det man ønsker 100% fordi:

1. Hvis man har tænkt på alt, har man stort set kodet systemet

2. Krav kan være åbne for fortolkning3. Verdenen bevæger sig

DEN PERFEKTE KRAVSPECIFIKATION

Personligt mener jeg ikke det er muligt at skrive en kravspecifikation, der rammer det man ønsker 100%...

FORDI:1. Hvis man har tænkt på alt, har man stort set

kodet systemet2. Krav kan være åbne for fortolkning3. Verdenen bevæger sig

HVAD GØR MAN SÅ?

• Sørg for at afklar, hvad der menes med kravene så tidligt i projektet som muligt

• Sørg for at have økonomisk luft i projektet til ændringsanmodninger

ANBEFALINGER

• Økonomisk og tidsmæssig buffer til ændringer• Afklar kravene med leverandøren tidligt i projektet• Tænk også på hvordan et krav skal testes/verificeres• Inkludér gerne ”catch all” krav• Stil krav til, hvad i vil opnå og ikke hvordan det skal løses• Værd bevist om fordele og ulemper ved mindstekrav• Husk lovgivningskrav, arkiveringskrav

???SPØRGSMÅL?-

LASSE GEISLERLAG@KOMBIT.DK??