PO_Lista_Icke-funktionella krav Ladoksystemet

Transkript

1 Ola Ljungkrona/Bo Sehlberg Sida: 1 (13) PO_Lista_Icke-funktionella krav Ladoksystemet

2 Ola Ljungkrona/Bo Sehlberg Sida: 2 (13) Innehållsförteckning 1 Inledning Icke-funktionella krav Användbarhet Information och dokumentation Användargränssnitt Gränssnitt Prestanda Svarstider Kapacitet Skalbarhet Säkerhet Kommunikation Identitet och behörighet Spårbarhet Åtkomst till information Molnet Tillförlitlighet Tillgänglighet Robusthet Underhållbarhet Arkitektur och design Loggning... 12

3 Ola Ljungkrona/Bo Sehlberg Sida: 3 (13) Revisionshistorik Utgåva Datum Författare Ändring Första utgåvan 2.0A Uppdatering efter avstämning i Expertgruppen. Borttagna krav: ANV Egenanpassade benämningar i användargränssnittet, ANV Egenanpassade benämningar i tjänstegränssnittet, SAK Extern behörighetskontroll, SAK Stark identitet, SAK Behörighet på data, UND Lärosätesanpassade moduler, UND Gemensam kärna. 2.0B Återställda och bearbetade krav: SAK-02-02, SAK-02-03, SAK-02-07, UND (sammanslaget med UND-01-03) Fastställd av Styrgrupp

4 Ola Ljungkrona/Bo Sehlberg Sida: 4 (13) 1 Inledning 1.1 Bakgrund Som ett led i att tydligöra de krav som inte är av funktionell karaktär har ett arbete gjorts för att sammanställa de icke funktionella krav som ställs på systemlösningen. Arbetet initierades som en utredning i förberedandefasen av Ladok 3-projeketet. Inom ramen för förberedelseprojektet utfördes en kartläggning av de Icke-funktionella krav som förekom bland annat i förstudier till Ladok3-projektet. Genomförandeprojektet har sorterat och bearbetat dessa krav vidare genom att urskilja och precisera relevanta icke-funktionella krav. Kraven ligger till grund för systemlösning och utgör även underlag för formulering av krav på drift och förvaltning. 1.2 Metod En arbetsgrupp med representanter från nuvarande drift, förvaltning, genomförandeprojektet och lärosätesrepresentanter sattes samman för att arbeta fram kravlistan i detta dokument. Arbetsgruppen: Ola Ljungkrona, sammankallande produktägare Ladok 3, Chalmers Peter Skov, utvecklare, LiU Anna-Karin Bergman, teknisk förvaltningsledare, VHS Gustav Almström, driftstekniker ladokdrift, LDC Mikael Håkansson, driftstekniker ladokdrift, LDC John Källström, driftstekniker ladokdrift, Umeå Malin Zingmark, PL förnyad förvaltning, Agio Arbetsgruppens resultat har granskats inom projektets produktmöte samt vid expertruppsmöte /11. Expertgruppen förordade vissa förtydliganden som ska återkopplas vid kommande möte /1. Godkänd kravlista tillgängliggörs via Ladok.se respektive projekt-wiki enligt samma principer som för övrig publik kravdokumentation under förutsättning att inte styrgruppen är av annan uppfattning.

5 Ola Ljungkrona/Bo Sehlberg Sida: 5 (13) 1.3 Genomförande Detta dokument beskriver de icke-funktionella krav som gäller för Ladok3-projektet. Ett ickefunktionellt krav beskriver HUR systemet skall fungera och kompletterar de funktionella kraven genom att beskriva systemets kvalitetsattribut. De icke-funktionella kraven har grupperats 1 i följande kravområden: Användbarhet Prestanda Säkerhet Tillförlitlighet Underhållbarhet 1.4 Acceptanskrav för överlämnandet till förvaltning De krav som förvaltningen kommer att ställa på överlämnandet för att säkerställa att den kan ta emot produkten finns beskrivna i detta dokument. Förvaltningen kommer att initiera en aktivitet som syftar till att utarbeta acceptanskrav som skall vara uppfyllda vid överlämning av Ladoksystemet från utvecklingsprojektet till förvaltningsorganisationen. Formerna för hur denna aktivitet skall bedrivas är ännu inte fastställda. Det övergripande målet då förvaltningen övertar ansvaret för det nya Ladoksystemet är att det skall vara förvaltningsbart. Förvaltningsorganisationen behöver specificera och kommunicera till Ladok3-projektet vilka kriterier som måste vara uppfyllda för att det nya Ladoksystemet skall anses vara förvaltningsbart. 1 Se rapport: LDPIckefunk_Rapport Icke-funktionella krav_v1.0.pdf

6 Ola Ljungkrona/Bo Sehlberg Sida: 6 (13) 2 Icke-funktionella krav De krav som har en []-kommentar efter beskrivningstexten finns beskrivna i LDPIckefunk_Rapport Icke-funktionella krav_v1.0, där även viss bakgrundsinformation kan hittas. 2.1 Användbarhet Information och dokumentation ANV Utbildningsmaterial Informations- och utbildningsmaterial för användandet av systemet skall ingå. [ANV-03-05] Informations- och utbildningsmaterialet skall anpassas för olika användare enligt följande: Drift Förvaltning Olika grupper av användare och i första hand fortbildare på lärosätet ANV Lätt att få hjälp Varje vy i systemet skall ha ett hjälpavsnitt som kan nås direkt från vyn. [ANV-03-07] ANV Dokumenterade förändringar Det skall finnas informationsmaterial och uppdaterat utbildningsmaterial för varje ny programvaruleverans. [ANV-08-01] ANV Systemdokumentation Det skall finnas uppdaterad och korrekt systemdokumentation tillgänglig Användargränssnitt ANV Vägledningen för webbutveckling Tillgängligheten ska anpassas till kraven i Vägledningen för webbutveckling från e- delegationen: ( [ANV-02-01] ANV Lätt att lära En användare med mycket goda studieadministrativa kunskaper skall inte behöva gå en kurs för att lära sig använda de grundläggande funktionerna i systemet för att genomföra sina arbetsuppgifter. [ANV-06-06] ANV Språkstöd användargränssnitt Det skall vara tekniskt enkelt att lägga till ytterligare språkstöd. Användargränssnittet skall stödja i första hand både svenska och engelska. ANV Språkstöd tjänstegränssnitt Tjänstegränssnittet skall stödja i första hand både svenska och engelska. Det skall vara tekniskt enkelt att lägga till ytterligare språkstöd. Olika deltjänster skall kunna stödja olika språk. ANV Stöd för olika webbrowsers

7 Ola Ljungkrona/Bo Sehlberg Sida: 7 (13) Systemet bör stödja webbrowsers med en marknadsandel på 5 % eller mer, men skall stödja följande browsers i rimligt sen version: Internet Explorer Firefox Chrome Safari En översikt av statistik på marknadsandelar för webbrowsers hittas på: Gränssnitt ANV Plattformsoberoende gränssnitt De gränssnitt systemet tillhandahåller skall vara möjliga att använda i olika typer av systemmiljö. Med systemmiljö avses här klientapplikationer, klienter och serversystem som existerar inom egen förvaltning och externt [DES-06-10] ANV Stabila gränssnitt De tekniska gränssnitt Ladok3-projektet tillhandahåller skall vara bakåtkompatibla, minst en major-version och samtliga minor-versioner, för att inte påverka integrationer vid en uppgradering. Max en majoruppgradering per år och att nästa major-version finns tillgänglig i produktion parallellt med tidigare i minst ett halvår. [INT-16] Teckenkodning ANV UTF-8 Systemet skall stödja och använda UTF-8 både i datalager och i webbgränssnitt. Systemet skall också kunna hantera anrop innehållande tecken 2 som kan göra att tjänsten inte klarar av att hantera frågan och därmed inte heller svarar. [ANV-01-01] 2.2 Prestanda Svarstider PRE Svarstider Svarstider delas upp i två kategorier: 1. Slutanvändargränssnitt 2. API Med svarstider avses den tid som det tar från det att klientförfrågan inkommer till systemet till dess att motsvarande svar returneras från systemet till klienten. Krav slutanvändargränssnitt: 2 Tecken såsom <Ctrl>, <Esc> etc.

8 Ola Ljungkrona/Bo Sehlberg Sida: 8 (13) För samtliga operationer, både läs- och skrivoperationer, skall måltiden för svarstiden normalt vara mindre än 1 sekund beroende av systemets belastning i övrigt inom ramen för vad SLA definierar som acceptabla nivåer. Krav API För samtliga operationer, både läs- och skrivoperationer, skall måltiden för svarstiden normalt vara mindre än 0,5 sekunder beroende av systemets belastning i övrigt inom ramen för vad SLA definierar som acceptabla nivåer. Varje tjänst skall ha ett tydligt SLA kopplat till sig. I SLA skall bl.a. svarstider anges. För de tjänster som inte kan leva upp till ovanstående nivåer p.g.a. designbegräsningar, skall det tydligt skrivas in vilka nivåer som aktuell tjänst klarar av att leverera. För ovanstående krav angående svarstider skall SLA definiera de exakta nivåerna på dessa, eftersom dessa krav kan vara kostnadsdrivande av förvaltningskostnaden så måste de exakta nivåerna tas fram i samråd med förvaltningen. [PRE-01] Kapacitet PRE Antalet studenter Systemet skall initialt vara dimensionerat för aktiva studenter på helårsbasis, men skall kunna dimensioneras upp när ökat behov uppstår. [PRE-04] PRE Antalet administrativa användare 3 Systemet skall vara dimensionerat för administrativ användare, dvs. användare som inte är studenter. [PRE-05] PRE Kapacitet Systemet skall klara av min sökningar/timme under bråd timme. Systemet skall klara av min registreringar/timme under bråd timme. Systemet skall klara av 4000 st samtidiga studentanvändare Systemet skall klara av 3000 st samtidiga expertanvändare Systemets interaktion med långsamma klienter ska inte vara så omfattande att Ladoks tjänster blir oanvändbara över en vanlig 3G-koppling, eller liknande Systemet skall klara av ovanstående krav i minst 8 timmar i sträck. (Bakgrunden till dessa två krav är baserat på erfarenheter från NyA, där man har c:a sökningar per bråd timme.) Skalbarhet PRE Elasticitet 4 3 Med administrativ menas här användare som har administrativa rättigheter i systemet, såsom lärare, utbildningssekreterare, handläggare, etc.

9 Ola Ljungkrona/Bo Sehlberg Sida: 9 (13) Den använda arkitekturen ska tillåta att systemleveransen från Ladok3-projektet kan skalas upp (och ner) både vertikalt 5 och horisontellt 6 för att kunna stödja de prestandakrav som satts i kraven i och Säkerhet Kommunikation SAK Krypterad kommunikation All extern kommunikation till/från systemleveransen från Ladok3-projektet ska ske krypterad. All intern kommunikation till/från komponenter som ligger externt 7 skall ske krypterat. SAK Anslutna system Anslutna system ska autentisera sig mot systemleveransen från Ladok3-projektet med klientcertifikat. Lärosäte skall kunna utfärda egna sub-certifikat så att lärosätet kan tillåta egna klienter att ansluta Identitet och behörighet SAK En unik identifierare, UUID 8, för varje students data Varje students data skall ha endast en identifierare i systemet oavsett lärosäte. [SAK-01-03] SAK Extern behörighetskontroll Behörighetskonfiguration skall kunna uppdateras från externt systemet. [SAK-26] SAK Stark identitet Autentiseringen mot systemet skall kunna ske med mer än bara ett användarnamn och ett lösenord. [SAK-01-04] SAK Certifikatbaserad identitet Användarens identitet skall kunna vara certifikatbaserad. [SAK-01-05] SAK Källsystem för behörighetssystem Systemet skall exponera sådan information att lärosätenas behörighetssystem (metakatalog) kan hantera uppgifter om studenternas behörigheter utifrån de aktiviteter de deltar i. [SAK-05] SAK Behörighet på roll För administrativa användare skall systemet använda roller för behörighetshanteringen SAK Behörighet på data 4 Definitioner på skalbarhet och elasticitet: 5 Vertikal skalning är inom server, dvs. större server 6 Horisontell skalning är parallellt, dvs. flera servrar. Det är enklare att skala horisontellt om molntjänster används. 7 Extern komponeter kan vara molntjänster såsom delar av Azure, Amazon, Google, etc. 8 UUID, Universally Unique IDentifier:

10 Ola Ljungkrona/Bo Sehlberg Sida: 10 (13) Det skall vara möjligt att sätta behörighet på data utifrån vilken organisation användaren har behörighet till Spårbarhet SAK Spårbarhet Se UND Åtkomst till information SAK Databasåtkomst Inga applikationer utanför systemet skall ha direkt tillgång till respektive tjänsts databas. SAK Databasåtkomst via SQL För läs- och skrivaccess av Ladok information skall funktionalitet skapas för att stödja detta. Funktionalitet för registervård skall tas fram för att rätta information som normalt inte skall ändras Molnet SAK Säkerhet i molnet Att förlägga en del av systemet i molnet skall inte kräva förändringar i systemets arkitektur och säkerhetsramverk. 2.4 Tillförlitlighet Tillgänglighet TIL Tillgänglighet Systemet skall ge möjlighet att mäta tillgänglighet så att dessa kan beskrivas i procent. Detta för att ge grund för vilka tillgänglighetskrav som kommer ställas på systemet. Tillgängligheten skall minst kunna erbjuda mätetal från: 1. Upptid inom olika mätintervaller såsom: a. Kontorstid b. Kvällstid c. Nattid d. Helgtid e. Total nertid f. Längd kontra antal avbrott g. Svarstider 2. Olika delsystem skall mätas 3. Upptid planerade avbrott 4. Upptid oplanerade avbrott

11 Ola Ljungkrona/Bo Sehlberg Sida: 11 (13) Rapporter på tillgängligheten skall kunna produceras med definierat tidsintervall alternativt anpassas så att dessa värden kan inhämtas av en övervakningsprogramvara. TIL Redundans Detta krav är endast till för att säkerställa den totala tillgängligheten. Kriterier för att bedöma redundansens bidrag till tillgänglighetskravet skall göras på följande delar: 1. Logisk datasäkerhet 2. Fysisk datasäkerhet 3. Infrastruktursäkerhet, hårdvara Systemet skall designas för att kunna användas i konfigurationer för redundans. [TIL-02] TIL Sömlös uppgradering Systemets delar skall designas för att kunna uppdateras var för sig utan att hela systemet behöver göras otillgängligt under uppgraderingen av respektive del. [UND-03-06] TIL Datatillförlitlighet All data skall verifieras med avseende på regelverk i respektive tjänst innan lagring. Systemet skall konstrueras enligt CAP 9 /ACID 10 principerna. [TIL-07] TIL Distribuering Varje tjänst skall designas så att de kan driftas i flera parallella instanser, både för lastfördelning, och av tillgänglighetsskäl Robusthet Dessa krav relaterar till förutsägbara händelser och inte till idag okända attacker. TIL Extrembelastning Systemet ska inte krascha eller stoppa okontrollerat vid extrem belastning. TIL Återhämtning Systemet ska kunna återhämta sig efter att ha utsatts för extrem belastning. TIL Konstanta svarstider Systemets svarstider ska vara konstanta över tiden oberoende av last i systemet. Undantag från detta krav kan vara om systemets utsätts för exempelvis en DOS-attack eller liknande. 2.5 Underhållbarhet Arkitektur och design Dessa krav är konkretiserade från dokumentet Ladok3 nationellt system 9 Consistency (all nodes see the same data at the same time), Availability (node failures do not prevent survivors from continuing to operate), Partition Tolerance (the system continues to operate despite arbitrary message loss) 10

12 Ola Ljungkrona/Bo Sehlberg Sida: 12 (13) UND Nationell installation Alla lärosäten skall använda samma nationella installation av systemet. Det skall inte finnas några parallella instanser 11 av systemet, annat än i lastdelnings- eller redundanssyfte. Utvecklingsmiljöerna skall vara gemensamma.[des-01-02] UND Lärosätesanpassning Systemet skall bestå av en kärna som kan utvidgas med funktionalitet för specifika ändamål via de gränssnitt (REST och Atom feeds) Ladok tillhandahåller. [DES-04-08] UND Tjänstebaserad arkitektur Systemet skall bygga på en tjänsteorienterad arkitektur. [DES-04-10] UND Designprincip Systemet bör designas för att ha en minimalistisk teknisk design. [DES-04-20] UND Begränsad databasåtkomst via SQL All logisk interaktion med systemets kärna skall ske via särskilda gränssnitt och inte via direkt SQL-access. Direkt SQL-access skall kunna ske mot lärosätesspecifik uppföljningsdatabas. [DDB-07] UND Dela central data mellan alla lärosäten För att underlätta underhåll av data skall data som delas mellan högskolor representeras på ett ställe. Exempel på sådana data är personuppgifter och kontaktuppgifter. [DDB-04] UND Ingen duplicering av logik En förändring av en affärsregel skall endast innebära ändring på ett ställe i systemet. [UND-02-01] UND Framtidsäker teknik Systemet skall byggas i en teknik som i dagsläget anses vara hållbar över tid och bedöms ha lång återstående livslängd. [UND-02-04] Loggning UND Loggning Systemet ska tillhandahålla loggningsinformation på ett så standardiserat 12 sätt som möjligt. Detta så att en övervakningsprogramvara kan läsa loggar och presentera informationen. UND Spårbarhet 11 Systemet kommer inte delas upp och serva några lärosäten som Ladok gör idag. Om det finns parallella instanser så är dessa kompletta och skiljer sig varken i konfiguration eller innehåll. 12 Beroende på operativsystem och mjukvara kan detta se olika ut. Det finns de facto -standarder för hur loggar ser ut inom ramen för Windows, Linux etc. Exempelvis kan en Oracle-databas logga Event i Eventloggen på en Windows server som sedan en övervakningsprogramvara kan läsa. Presentationen av Eventen kan sedan anpassas hur dessa skall presenteras och vilka åtgärder som skall starta för dessa.

13 Ola Ljungkrona/Bo Sehlberg Sida: 13 (13) Systemet skall ge spårbarhet enligt gällande förordningar. Exempel på gällande förordningar: 1. Studiedokumentationsförordningen - Förordning (1993:1153) om redovisning av studier m.m. vid universitet och högskolor 2. Personuppgiftslag (1998:204) UND Felsökning loggning Drift- och supportorganisationen skall ha tillgång till omfattande stöd för felsökning för att kunna felsöka olika fel såsom: 1. Integrationsfel 2. Inmatningsfel 3. Tjänsteanropsfel 4. Interna systemfel UND Support I de fall lärosätet inte själv kan göra det med tillgängliga verktyg, ska drifts- och supportorganisation tillhandahålla support för felsökning åt lärosäte. Rapporter skall finnas så att lärosätet kan säkerställa att information i Ladok är korrekt.