Funksjonelle krav. Løsningen skal støtte ulike klient operativsystem (OSE), så som Windows, Linux, Mac, Unix Verktøyet skal kunne gjenkjenne alle kjente applikasjoner og kjørende instanser Verktøyet skal kunne konfigureres slik at det kan gjenkjenne spesifikke programvarepakker og suiter Verktøyet skal ha muligheter til å allokere spesielle lisensmetrikker til applikasjoner og suiter Verktøyet skal inneholde funksjonalitet som automatisk kan sette oppgraderings- og nedgraderingsmuligheter i spesifikke situasjoner Verktøyet skal kunne håndtere flere versjoner av samme produkt på samme OSE Verktøyet skal automatisk kunne identifisere og allokere riktig Product Use Right til en lisens som importeres ved bruk av SKU nummer Det skal være mulig å legge inn egendefinerte lisensmodeller som ikke kommer out-of-the-box Ved granskning av en lisens skal verktøyet kunne vise alle maskiner/enheter/devices som konsumerer lisensen, samt alle tilknytninger og organisasjoner/brukere Ved granskning av en applikasjon skal verktøyet kunne vise alle maskiner/enheter/devices som har applikasjonen installert, samt versjonsnummer Verktøyet skal kunne måle bruk av programvare (software metering og bruk) Verktøyet skal kunne gi brukshistorikk selv om klienten ikke er tilkoblet nettverket til enhver tid Verktøyet skal kunne integreres i eksternt skybaserte lisenstjenester, som Adobe Creative Cloud og Microsoft Office365 (SaaS) Verktøyet skal fungere i eksterne skytjenester, som Amazon WS og Microsoft Azure (PaaS) Verktøyet skal kunne lage og vise koblinger mellom brukere (users) og maskinvare (devices) Verktøyet skal ha muligheter til å legge inn spesielle kontraktsvilkår og kontraktstillegg (amendments). For eksempel begrensede oppgraderingsrettigheter eller product use rights Verktøyet skal støtte overføring av lisenser mellom underliggende virksomheter eller andre avdelinger Verktøyet skal ha et enkelt brukergrensesnitt og det skal være mulig å lage og ta ut enkle rapporter for ansatte med forskjellige funksjoner i virksomheten. Verktøyet skal kunne installeres, konfigureres og rulles ut On-premise på Kundens tekniske plattform På datacenter plattformen skal verktøyet både ha mulighet for innhenting og bearbeidelse av data via standard klientprogramvare og spesifikk scripting dersom det er behov for det Verktøyet skal ha integrert støtte for programvaregjenkjenning (discovery) og innsamling av data mot de mest kjente applikasjons-virtualiseringsplattformene (MS App-V og VMware VDI) Det skal være mul...
Funksjonelle krav. En av forskjellene i denne avtalen sammenlignet med SSA-U og SSA-T er at Kunden og Leverandøren skal samarbeide om å spesifisere Funksjonelle krav ut fra formåls- og behovsbeskrivelsen i konkurransegrunnlaget. Behovsbeskrivelsen kan for eksempel være gitt i form av Brukerhistorier og Epos. Forskjellen på en Brukerhistorie og et Epos er størrelsen. Et Epos er en stor Brukerhistorie. Både Epos og Brukerhistorier har formen: ”Som saksbehandler ønsker jeg å legge inn informasjon om en sak slik at jeg kan slippe å registrere denne informasjonen på nytt hver gang det kommer inn et nytt dokument på saken.” ”Som linjeleder ønsker jeg å kunne ta ut rapporter over hvilke saker mine medarbeidere jobber med slik at jeg kan holde oversikt over hvem som jobber med hva” ”Som prosjektleder ønsker jeg å få oversikt over alle timelister de innleide konsulentene har sendt siste måned slik at jeg kan holde oversikt over hvor mange timer som har påløpt” Alle roller som inngår i Brukerhistoriene må være definerte: Dersom programvareutviklingen er basert på scrum, vil de Funksjonelle kravene ligge i en produktkø (product backlog) som Kundens produkteier senere skal prioritere før oppstart av hver sprint.
Funksjonelle krav. Hva skal systemet gjøre? Xxxxxx mål skal det tilfredstille? Ikke-funksjonelle krav: Produktkrav: hvordan skal produktet fungere? Organisatoriske krav: hvordan skal systemutviklingsprosessen gjennomføres? Skal være mål/testbare - presise! Eksempler:
Funksjonelle krav. Kundens funksjonelle behov og krav til løsning spesifiseres i kapitlene under. Leverandøren skal besvare kravene i SSA-L Bilag 2 Leverandørens løsningsspesifikasjon. Der leverandøren i sin besvarelse refererer til sin egen dokumentasjon skal nøyaktig plassering (kapittel, avsnitt, punkt etc. oppgis).
Funksjonelle krav. Kravene skal besvares i Bilag 2 - Leverandørens beskrivelse av tjenesten. Noen krav har uthevet skrift. Det markerer at innfrielse av disse kravene forutsetter integrasjoner mot Trondheim kommunes saksbehandlingssystem (for tiden ESA8). Dette er nærmere beskrevet i kapittel 6.
Funksjonelle krav. Leveransen skal minimum tilfredsstille krav i henhold til Fellesoverenskomsten for byggfag 2020–2022 mellom NHO og LO, jfr. bilag 20 i overenskomsten. Både del A, B og D vil komme til anvendelse for riggen. • Leveransen skal minimum tilfredsstille krav som fremkommer av øvrige lover, forskrifter eller annet regelverk, herunder arbeidsmiljøloven og arbeidsplassforskriften • Det er krav om universell utforming av kantinen, første etasje i kontorrigg og første etasje i minimum én av boligriggene
Funksjonelle krav. Løsningen skal støtte ulike klient operativsystem (OSE), så som Windows, Linux, Mac, Unix M11 Verktøyet skal kunne gjenkjenne alle kjente applikasjoner og kjørende instanser
Funksjonelle krav. Dette kapittelet inneholder Kundens funksjonelle krav, som Leverandøren skal besvare i Bilag 2.
Funksjonelle krav. Generelle krav: Krav Kundens behov
a) Driftsverktøy til løsningen skal holdes oppdatert til å kunne kjøres på nye versjoner av operativsystem, nettlesere og ev. bakenforliggende motorer som dot net, Java etc. Dette gjelder både serverinstallasjoner og klientinstallasjoner (PCer, nettbrett, smarttelefoner).
b) Alle nødvendige verktøy for å endre og konfigurere (lokalt) skal medfølge leveransen.
Funksjonelle krav. (samhandling med delområde 1 - Fase 1)