115
records
| Requirement-id | Kategori | requirement | requirements when IT-operations within the buyers own datacenter | requirements when IT-operations runs in the sellers datacenter | The recommended form for the requirement is should | The recommended form for the requirement is shall |
|---|
| Requirement-id | Kategori | requirement | requirements when IT-operations within the buyers own datacenter | requirements when IT-operations runs in the sellers datacenter | The recommended form for the requirement is should | The recommended form for the requirement is shall | |
|---|---|---|---|---|---|---|---|
1 | 181 | Federation | Federeringen, när det gäller SAML2, bör ansluta mot den federerande partnerns metadata och läsas av samt uppdateras med automatik vid förändringar. Redovisa hur detta går till. | Ja | Ja | Ja | Nej |
2 | 180 | Digital post | Säljarens verksamhetssystem bör tillhanda funktioner för att via DIGG:s infrastruktur för digital post, Mina meddelanden, förmedla avsändarens (kommunens) meddelanden/brev till rätt brevlåda. Säljaren och deras verksamhetssystem tillhandahåller nödvändig funktionalitet för att leverera digital post via Mina meddelanden till rätt brevlåda. | Ja | Ja | Ja | Nej |
3 | 179 | Digital post | Säljarens verksamhetssystem bör tillhanda funktioner för att via DIGG:s infrastruktur för digital post, Mina meddelanden, förmedla avsändarens (kommunens) meddelanden/brev till rätt brevlåda. Verksamhetssystemet bör kunna leverera en utskriftsfil med erforderliga uppgifter för mottagaren och det egentliga brevet enligt av köparens angivet format, se bilaga x. | Ja | Ja | Ja | Nej |
4 | 178 | Integrationer | Umeå kommun har för avsikt att bygga egna e-tjänster enligt vår e-servicestrategi. På förfrågan från köparen ska leverantören, där det finns tillgängliga API:er, från identifierade delområden/processer, ge tillgång till API:er för att möjliggöra köparen att bygga egna e-tjänster. | Ja | Ja | Nej | Ja |
5 | 177 | Automation | Umeå kommun har som ambition att under avtalstiden, så långt det är möjligt automatisera manuella ärendeflöden i systemet. I vissa fall är vår enda möjlighet att använda RPA automation. På förfrågan från köparen ska leverantören, vara behjälplig i köparens arbete med RPA automation. | Ja | Ja | Nej | Ja |
6 | 176 | Dokumentation | Det bör finnas en teknisk beskrivning av systemets integrationsmöjligheter som helst bör vara i en öppen form, exempelvis en Swagger enligt standarden OpenAPI.
Bifoga den tekniska beskrivningen. | Ja | Ja | Ja | Nej |
7 | 175 | Backup | Backup ska ske minst en gång per dygn. Backup ska normalt ske nattetid. | Nej | Ja | Nej | Ja |
8 | 174 | Mobil användbarhet | Köparen har som ambition att under avtalstiden, så långt det är möjligt erbjuda våra kunder (leverantörer/föräldrar/brukare/patient och/patientföreträdare/mm) att arbeta mobilt på andra sätt än via användarvänliga appar (ex. via responsiv webbsida designad för handhållna enheter).
Det bör vara möjligt att skapa, läsa, uppdatera, radera information i systemets användardialoger (ärendeflöden formulär mm) där kunden kan tillåtas behörigheter. Vi vill alltså att relevanta delar av verksamhetsprocessen som utförs via användargränssnitt på stationär dator med tangentbord, ska gå att genomföra på handhållen enhet med pekskärm (mobile first). Vi vill också att kunden (brukaren mm) själv är huvudaktör i alla processer som inte kräver engagemang (beslut behörighet) av köparens tjänstepersoner, i syfte att minska vår egen administrativa börda. Beskriv hur börkravet uppfylls för de delar av systemet som är riktade mot kommunens kunder. | Ja | Ja | Ja | Nej |
9 | 173 | Mobil användbarhet | Köparen har som ambition att under avtalstiden, så långt det är möjligt erbjuda våra egna användare att arbeta mobilt på andra sätt än via användarvänliga appar (ex. via responsiv webbsida designad för handhållna enheter).
Det bör vara möjligt att skapa, läsa, uppdatera, radera information i systemets användardialoger (ärendeflöden formulär mm). Vi vill alltså att relevanta delar av verksamhetsprocessen som utförs via användargränssnitt på stationär dator med tangentbord, ska gå att genomföra på handhållen enhet med pekskärm (mobile first). Beskriv hur börkravet uppfylls för de delar av systemet som är riktade mot köparens tjänstepersoner. | Ja | Ja | Ja | Nej |
10 | 172 | Integrationer | Säljaren ska bistå köparen vid implementation av aktuella och framtida RPA robotar inklusive acceptanstest om köparen så begär. Redogör för hur er samverkansprocess ser ut i samband med etablering av befintliga och framtida RPA robotar samt ekonomisk modell för denna samverkan. | Ja | Ja | Nej | Ja |
11 | 171 | Integrationer | Säljaren ska bistå köparen vid implementation av aktuella och framtida integrationer inklusive acceptanstest om köparen så begär. Redogör för hur er samverkansprocess ser ut i samband med etablering av befintliga och framtida integrationer. | Ja | Ja | Nej | Ja |
12 | 166 | 3D | Köparen ska ha nyttjande- och äganderätt till det 3D-data som skapats i säljarens lösning för användande i sin övriga verksamhet. | Ja | Ja | Nej | Ja |
13 | 165 | 3D | Säljarens lösning ska klara av att exportera de 3D-modeller som framställts i formatet Collada (.dae ) | Ja | Ja | Nej | Ja |
14 | 164 | Ruttoptimering | Säljarens lösning bör möjliggöra för utföraren, när denne är i fält, baserat på omedelbara uppkomna händelser (ex punktering, egensjukdom, trafiksituation, hittar ej parkering, avbokning av stoppet med kort varsel), att kunna justera sin individuella planering och därmed initiera en ny ruttoptimering som gäller för den aktuella utföraren (och som visas på den aktuella utförarens enhet). Redovisa hur börkravet uppfylls. | Ja | Ja | Ja | Nej |
15 | 163 | Ruttoptimering | Säljarens lösning bör vid en justering av den övergripande planeringen enligt ovan, klara av att räkna om rutten enbart baserat på den gjorda justeringen i syfte att minska beräkningstiden för ny rutt. Redovisa hur börkravet uppfylls. | Ja | Ja | Ja | Nej |
16 | 162 | Ruttoptimering | Den övergripande strategiska planeringen, gällande tidsfönster för utförarens raster (lunch, kaffe, vilotider, dygnsvila, veckovila mm), i säljarens lösning bör gå att justera och räknas om med kort varsel ex. i början av ett arbetspass och för en avgränsad period (ex. idag på förmiddagen) utan att behöva göra om den övergripande strategiska planeringen i sin helhet. Redovisa hur börkravet uppfylls. | Ja | Ja | Ja | Nej |
17 | 161 | Ruttoptimering | Säljarens lösning bör inkludera strategisk planering där tidsfönster för utförarens raster (lunch, kaffe, vilotider, dygnsvila, veckovila mm) markeras på ett övergripande sätt för valfri kalenderperiod. Redovisa hur börkravet uppfylls. | Ja | Ja | Ja | Nej |
18 | 160 | Ruttoptimering | Säljarens lösning bör klara av att ta hänsyn till servicetid (hanteringstid, tid på plats, osv), exempelvis att stoppet följs direkt av en tid som utföraren behöver befinna sig på den platsen innan rutten kan fortsätta. Redovisa hur börkravet uppfylls | Ja | Ja | Ja | Nej |
19 | 159 | Ruttoptimering | Säljarens lösning bör klara av att ta hänsyn till en eller flera tidsfönster i rutten, exempelvis att stoppet/avlämningspunkten (kunden, brukaren, porten) endast är på plats/öppen vissa specifika tider. Redovisa hur börkravet uppfylls. | Ja | Ja | Ja | Nej |
20 | 158 | Ruttoptimering | Säljarens lösning bör i samband med ruttoptimering klara av att inkludera/ variera fordonstyper i den planerade rutten, så kallad "Park and loop" (ex. först bil sedan cykel se. Redovisa hur börkravet uppfylls. | Ja | Ja | Ja | Nej |
21 | 157 | Kartdata och bakgrundskartor | I händelse av att säljarens lösning av någon anledning inte kan koppla upp sig mot ”Umeå kommuns karttjänster” ska säljaren redovisa aktuell källa för kartdata på begäran av köparen. | Ja | Ja | Nej | Ja |
22 | 156 | Kartdata och bakgrundskartor | Säljarens lösning bör använda sig av Umeå kommuns karttjänster för att nyttja t ex populärnamn och annan geografisk data som köparen tillhandahåller och som endast finns tillgängligt hos köparen | Ja | Ja | Ja | Nej |
23 | 155 | Kartdata och bakgrundskartor | Säljarens lösning ska följa svensk standard för hur adress beskrivs.
Belägenhetsadress: SS 637003:2015 Postaladress: ISO 19160-4:2017 | Ja | Ja | Nej | Ja |
24 | 154 | Kartdata och bakgrundskartor | Säljarens lösning bör använda svenska nationella geostandarder för hur data/information lagras, sorteras och beskrivs. Redovisa hur börkravet uppfylls | Ja | Ja | Ja | Nej |
25 | 153 | Kartdata och bakgrundskartor | Om säljarens lösning inte hanterar Sweref 99 20 15 eller Sweref 99 TM bör säljarens lösning hantera WGS84. Redovisa hur börkravet uppfylls. | Ja | Ja | Ja | Nej |
26 | 152 | Kartdata och bakgrundskartor | Om säljarens lösning inte hanterar Sweref 99 20 15 bör säljarens lösning hantera Sweref 99 TM. Redovisa hur börkravet uppfylls. | Ja | Ja | Ja | Nej |
27 | 151 | Kartdata och bakgrundskartor | Köparen använder koordinatsystemet Sweref 99 20 15 i den kartdata som produceras och lagras hos köparen. Säljarens lösning bör hantera Sweref 99 20 15 . Redovisa hur börkravet uppfylls. | Ja | Ja | Ja | Nej |
28 | 150 | Kartdata och bakgrundskartor | Säljarens lösning bör använda API eller WFS enligt senaste versionen av OGC-standard för att kunna tillhandahålla kartdata till köparens karttjänster eller andra system. Redovisa hur börkravet uppfylls. | Ja | Ja | Ja | Nej |
29 | 149 | Kartdata och bakgrundskartor | Säljarens lösning bör använda WMTS eller WFS enligt senaste versionen av OGC-standard för att kunna visa och nyttja kartdata. Redovisa hur börkravet uppfylls. | Ja | Ja | Ja | Nej |
30 | 148 | Överläsning till e-arkiv | Handlingar/dokumentation och kontexten ska fortlöpande (och vid valfri tidpunkt) kunna exporteras (till e-arkiv/mellanarkiv) ur det IT-system som säljaren levererar enligt befintlig teknisk kravspecifikation från köparen. | Ja | Ja | Nej | Ja |
31 | 147 | Överläsning till e-arkiv | Säljaren ska läsa in handlingar och dokumentation från köparens e-arkiv eller mellanarkiv enligt befintlig teknisk kravspecifikation i samband med att det gamla systemet (som ersätts av det nya från säljaren) avvecklas. | Ja | Ja | Nej | Ja |
32 | 146 | Utskrifter | Utskrifter bör fungera med köparens ordinarie skrivardrivrutiner, som använder PCL. Beskriv hur detta görs. | Ja | Ja | Ja | Nej |
33 | 145 | Drift och testmiljö | Säljarens lösning ska använda Windows standard för utskrifter kopplad till inloggad användare. | Ja | Ja | Nej | Ja |
34 | 144 | Drift och testmiljö | Information (data) som säljarens lösning lagrar i SQL-databaser ska använda (fungera med) Microsoft SQL Server 2017 eller senare som databasmotor | Ja | Nej | Nej | Ja |
35 | 143 | Drift och testmiljö | Redovisa för vilken plattform som ingående delar i säljarens lösning är kompilerade. | Ja | Nej | Nej | Ja |
36 | 142 | Drift och testmiljö | Serverdelen av säljarens lösning ska vara kompilerat och körbart för / på x64 plattformar | Ja | Nej | Nej | Ja |
37 | 141 | Drift och testmiljö | Redovisa vilka prestandakrav som säljarens lösning ställer på köparens datacenter. | Ja | Nej | Nej | Ja |
38 | 140 | Drift och testmiljö | Säljarens lösning ska klara av att exekvera i en virtualiseringsmotor (hypervisor VMware vSphere 6.5) | Ja | Nej | Nej | Ja |
39 | 139 | Klientplattform | Säljarens lösning ska fungera med köparens nuvarande antivirusmiljö, f n Windows Defender och Cylance Protect. | Ja | Ja | Nej | Ja |
40 | 138 | Klientplattform | De delar av säljarens lösning som utnyttjar Microsoft Office ska fungera med senaste versionen av Microsoft Office 365 | Ja | Ja | Nej | Ja |
41 | 137 | Klientplattform | Säljarens lösning ska stödja applikationsdistribution genom Microsoft Intune. Det gäller exempelvis LOB-applikationer eller Win32-applikationer (paketerade applikationer) | Ja | Ja | Nej | Ja |
42 | 136 | Klientplattform | Säljarens lösning ska fungera på klientdatorer som kommunicerar via Microsoft Direct Access | Ja | Ja | Nej | Ja |
43 | 135 | Klientplattform | Säljarens lösning ska fungera på klientdatorer som är krypterade med Microsoft Windows Bitlocker | Ja | Ja | Nej | Ja |
44 | 134 | Federation | Köparen har separata ADFS servrar för elever och personal. Säljarens lösning bör klara att hantera federation mot flera ADFS servrar samtidigt. Redovisa hur flera ADFS servrar kan konfigureras i systemet | Ja | Ja | Nej | Ja |
45 | 133 | Integrationer | Redovisa exempel på hur ni brukar dokumentera integrationer | Ja | Ja | Nej | Ja |
46 | 132 | Integrationer | Säljaren ska dokumentera alla integrationer (Tjänstekontrakt) i lösningen/systemet enligt vid var tid gällande mall från köparen. | Ja | Ja | Nej | Ja |
47 | 130 | Integrationer | Alla integrationer i säljarens lösning/systemet ska godkännas av köparens IT- funktion innan de tas i bruk | Ja | Ja | Nej | Ja |
48 | 129 | Integrationer | Redovisa åtgärder som behöver genomföras i köparens befintliga infrastruktur, för att säkerställa säkerhet, vid informationsöverföring (In Transit) via systemets öppna api:er | Ja | Ja | Nej | Ja |
49 | 128 | Integrationer | Befintliga, och under avtalstiden tillkommande öppna api:er i säljarens lösning ska ha inbyggd säkerhet (Privacy by design) | Ja | Ja | Nej | Ja |
50 | 127 | Integrationer | API:erna bör vara åtkomstbara för köparen, ha en rimlig säkerhet, och följa REST-principer. Den information som exponeras bör vara i ett JSON-format enligt RFC 4627. Redogör hur börkravet uppfylls. | Ja | Ja | Ja | Nej |
51 | 126 | Integrationer | Öppna api:er i säljarens lösning/systemet bör vara baserade på REST eller motsvarande. Redogör hur börkravet uppfylls. | Ja | Ja | Ja | Nej |
52 | 125 | Integrationer | Integrationer bör ske via systemets öppna api:er. Redogör hur börkravet uppfylls. | Ja | Ja | Ja | Nej |
53 | 124 | Integrationer | Köparen har för avsikt att bygga egna e-Tjänster och försystem som nyttjar systemets API:er för att skapa, läsa, uppdatera, radera information i systemet enligt den logik och regelverk systemet erbjuder. Säljarens lösning/systemet bör erbjuda möjlighet för köparen att utveckla egna e-tjänster och försystem som via apianrop interagerar med systemet i realtid. Beskriv hur börkravet uppfylls. | Ja | Ja | Ja | Nej |
54 | 123 | Integrationer | Köparen har som ambition att under avtalstiden, så långt det är möjligt automatisera manuella ärendeflöden i systemet. Det bör vara möjligt att skapa, läsa, uppdatera, radera information i systemets alla användardialoger (ärendeflöden formulär mm) via API:er. Vi vill alltså att alla delar av verksamhetsprocessen som utförs via användargränssnitt av våra användare även ska gå att automatisera via systemets API:er. Beskriv hur börkravet uppfylls. | Ja | Ja | Ja | Nej |
55 | 94 | Arkitektur | Köparen strävar efter en applikationsarkitektur som baseras på mikrotjänster och öppna api:er. Säljarens lösning/systemet bör vara byggt med öppna API:er som är tillgängliga för köparens utvecklare. Redogör hur börkravet uppfylls. | Ja | Ja | Ja | Nej |
56 | 93 | Teknisk miljö | Redovisa vad som krävs för att lösning av klient/server-typ ska fungera i köparens befintliga infrastruktur. | Ja | Ja | Nej | Ja |
57 | 92 | Teknisk miljö | Ifall delar av säljarens lösning är av klient/server-typ så ska förutsättningarna för den lösningen beskrivas. | Ja | Ja | Nej | Ja |
58 | 91 | Teknisk miljö | Säljarens lösning bör kunna användas via webbläsare. Redogör hur börkravet uppfylls. | Ja | Ja | Ja | Nej |
59 | 90 | Teknisk miljö | Redovisa på vilket sätt säljarens lösning/systemet passar in i miljöer med operativsystem från Microsoft. | Ja | Ja | Nej | Ja |
60 | 89 | Teknisk miljö | Köparen har en tydlig Microsoft-strategi på klient- och serversida. Säljarens lösning/systemet ska fungera i köparens miljöer med server / klient operativsystem från Microsoft. | Ja | Ja | Nej | Ja |
61 | 88 | Säkerhet | Säljarens lösning bör ha stöd för rollbaserade rättigheter där användare tilldelas en eller flera roller. Redogör hur börkravet uppfylls. | Ja | Ja | Ja | Nej |
62 | 87 | Säkerhet | Säljaren ska ha rutiner för informationssäkerhet vid byte, transport, underhåll och utrangering av utrustning som innehåller köparens data. | Nej | Ja | Nej | Ja |
63 | 86 | Säkerhet | Säljaren ska ha en implementerad informationssäkerhetspolicy samt en organisation som ansvarar för att kontinuerligt underhålla och förbättra informationssäkerheten. | Ja | Ja | Nej | Ja |
64 | 85 | Säkerhet | Fjärråtkomst för tekniskt förvaltning, support som säljaren tillhandahåller för lösningen/systemet nås med verktyg och behörigheter som tillhandahålls och bestäms av köparen. | Ja | Nej | Nej | Ja |
65 | 84 | Säkerhet | Köparen ska i samråd med säljaren ha rätt att genomföra säkerhetsgranskningar av ingående delar i leveransen. | Ja | Ja | Nej | Ja |
66 | 83 | Säkerhet | Säljarens lösning bör utformas så att risk för intrång i servermiljön minimeras. Redogör hur börkravet uppfylls. | Ja | Ja | Ja | Nej |
67 | 82 | Utbildning | Ange i anbudet förslag på utbildning kring offererad applikation samt alla kostnader som är förenligt med detta. | Ja | Ja | Nej | Ja |
68 | 81 | Acceptanstest | Säljaren ska bistå köparen vid acceptanstest av prestanda i säljarens lösning om så köparen begär. | Ja | Ja | Nej | Ja |
69 | 74 | Digital signatur | Säljarens lösning/systemet bör klara av att genomföra e-underskrifter genom att att systemet implementerat designmönster för digital signatur via fristående underskriftstjänst. (se Referensarkitektur för elektronisk underskrift och stämpel Rev A, 5.2.2.3 Principiellt flöde för digital signatur via underskriftstjänst). Beskriv minst på vilket sätt systemet kan integreras för att få elektronisk underskrift. Beskriv även om systemet kan skapa dokument i filformatet inbäddad PDF/A-2 LT och som baseras på PAdES för underskrift via integration till befintlig fristående underskrifttjänst.
https://rivta.se/documents/ARK_0060/Referensarkitektur_for_elektronisk_underskrift_och_stampel_RevA.pdf | Ja | Ja | Ja | Nej |
70 | 52 | Autentisering | Köparen använder främst SAML 2 samt OpenID connect när tjänsteperson tillhörande kommunen autentiserar sig mot upphandlade tjänster och ser dessa som strategiska vägval. SAML 2 samt OpenID connect är de primära sätten att autentisera användare och säljarens lösning bör klara någon av dessa för samtliga ingående komponenter i leveransen . Beskriv hur lösningen kan integreras med köparens lösning för federation. | Ja | Ja | Ja | Nej |
71 | 51 | Autentisering | Redovisa hur säljarens lösning använder Active Directory. Aktivt och online eller genom import av AD-data | Ja | Ja | Nej | Ja |
72 | 50 | Autentisering | Säljarens lösning ska kunna använda Active Directory för användarautentisering | Ja | Ja | Nej | Ja |
73 | 49 | Datalager | Säljarens lösning/systemet bör tillåta annan tillgång till data för datauttag till datalagret än data anordnad i dimensions- och faktatabeller eller direkt åtkomst till databastabeller. Redogör hur börkravet uppfylls. | Ja | Ja | Ja | Nej |
74 | 48 | Datalager | Säljarens lösning/systemet bör tillåta direkt tillgång till databastabeller för datauttag till datalagret. Redogör hur börkravet uppfylls. | Ja | Ja | Ja | Nej |
75 | 47 | Datalager | Säljarens lösning/systemet bör tillhandahålla data anordnad i dimensions- och faktatabeller för datauttag till datalagret. Redogör hur börkravet uppfylls. | Ja | Ja | Ja | Nej |
76 | 46 | Datalager | Köparen använder ett datalager för sammanställning och analys av data från flera källor. Säljarens lösning/systemet ska stödja datauttag till datalagret eller ha ett eget datalager med uppgifter som gör att datat kan kopplas till köparens datalager. | Ja | Ja | Nej | Ja |
77 | 43 | Klientplattform | Funktionalitet i säljarens lösning bör inte vara beroende av tilläggsprogramvaror till webbläsare. Redogör hur börkravet uppfylls. | Ja | Ja | Ja | Nej |
78 | 42 | Klientplattform | Säljarens lösning ska ha full funktion med enbart användarbehörigheter på lokal dator. | Ja | Ja | Nej | Ja |
79 | 41 | Klientplattform | Säljarens lösning ska konsekvent stödja klientexekvering via Remote Desktop och Citrix XenApp. | Ja | Nej | Nej | Ja |
80 | 40 | Klientplattform | Säljarens lösning ska stödja Windows 10 x64 | Ja | Ja | Nej | Ja |
No results