Krav för en upphandling
Ett urval att skriva specen ur, inte en lista att skicka. 344 krav i biblioteket.
Först familj, sedan kärnkrav i det som syns. Kryssa det som gäller. Valda visar bara det ni markerat.
378 rader · 0 valda
Kärnkrav har den här bakgrunden. Familjerna väljer vad som syns. Kärnkrav begränsar till kärnkraven i det visade.
| Krav | Familj | Not | |
|---|---|---|---|
| Plattform och arkitektur 2 krav · 1 kärnkrav · 0 valda Flexibilitet, skalbarhet och mindre inlåsning. | |||
|
Kräv en uppdelning per flöde av vilka steg som ger samma utdata för samma indata och vilka som inte gör det, redovisad mot arkitekturen. |
Byta | ||
|
Kräv besked om var filtreringen sker, i sökfrågan eller på träfflistan efteråt, och att svaret går att granska mot en arkitekturbeskrivning i stället för att stanna vid ett ja. |
Byta | ||
| Funktionalitet 43 krav · 41 kärnkrav · 0 valda Vad lösningen ska göra för den som använder den. | |||
|
Kräv i stället att alla inställningar som påverkar variationen är dokumenterade och att ni kan sätta dem per användningsfall. |
— | ||
|
Kräv att utvärdering redovisas som upprepade körningar av en fråguppsättning som ni själva bidrar med, med spridning och andel felaktiga svar per fråga. |
Mäta | ||
|
Kräv skriftligt besked i förväg när något ändras som påverkar utfallet. |
— | ||
|
Kräv att antalet anrop per användarhandling redovisas: en fråga i gränssnittet kan bli fem anrop, och de dolda anropen (omformuleringar, sökningar, sammanfattningar) skickar in underlag som ingen har bett om. |
— | ||
|
Kräv ett tak som ni själva sätter, per anrop och per ärende, och som stannar flödet i stället för att korta underlaget tyst. |
— | ||
|
Kräv att fönstrets gräns anges för den konfiguration ni köper, och att en ändring av gränsen meddelas skriftligen, eftersom den ändrar vad som fungerar hos er. |
— | ||
|
Kräv en beskrivning av hur underlaget väljs ut inför varje anrop, hur mycket som skickas med, och att mängden går att ställa in av er. |
— | ||
|
Kräv att varje svar anger vilka avsnitt och vilken version det vilar på, så att en handläggare kan se om svaret byggde på den handbok som gäller i dag. |
— | ||
|
Kräv att kvaliteten redovisas för realistiska volymer: samma fråguppsättning körd mot ett litet och ett stort underlag, och i ett nystartat respektive långt samtal, med resultatet redovisat per fall. |
— | ||
|
Kräv att lösningen kan starta ett nytt samtal per ärende. |
— | ||
|
Kräv att leverantören beskriver vad som händer när två avsnitt i underlaget säger olika, och att utgångna versioner går att märka eller ta bort. |
— | ||
|
Kräv en förteckning över varje plats där prompt, svar och sparat minne lagras, med system, land, huvudman och lagringstid per plats. |
— | ||
|
Kräv att lagringstiden är en inställning som ni styr. |
— | ||
|
Kräv ett avtalat förbud mot att era uppgifter används för träning eller produktförbättring, inte bara en kryssruta i gränssnittet. |
— | ||
|
Kräv en skriftlig förteckning över varje del som sätts ihop till ett anrop, i den ordning delarna sätts, med angiven avsändare per del: ni, leverantören, ett automatiskt steg eller användaren. |
— | ||
|
Kräv att en ny del inte tillförs utan ert godkännande. En tillagd del ändrar svaren utan att någon rört er instruktion, och utan förteckningen finns ingenting att jämföra mot. |
— | ||
|
Kräv att den sammansatta texten kan visas uppdelad i sina delar med källa angiven per del, inte som ett odelat block, så att det syns varifrån ett visst påstående kom. |
— | ||
|
Kräv att de delar ni äger går att ändra av er själva, och angiven ledtid för de delar som kräver leverantörens medverkan. |
— | ||
|
Kräv att formen levereras som ett maskinläsbart schema, inte som en beskrivning i löptext, och att schemat är ert. |
— | ||
|
Kräv ett avtalat beteende per flöde när ett svar underkänns, och att delvis skrivning aldrig sker. |
— | ||
|
Kräv att andelen underkända svar redovisas löpande per flöde: den siffran är det tidigaste tecknet på att något ändrats. |
— | ||
|
Kräv att en ändring av schemat är versionerad och meddelas i förväg, eftersom ett nytt fält eller ett borttaget värde bryter mottagarsystemet lika hårt som ett driftavbrott. |
— | ||
|
Kräv att systemprompten lämnas till er i klartext och att ni får ändra den själva. |
— | ||
|
Kräv att leverantören inte ändrar er lydelse i en produktuppdatering. |
— | ||
|
Kräv att produktens egna instruktionslager utöver ert redovisas och att en ändring i dem meddelas skriftligt, eftersom ert system annars ändras utan att er text gör det. |
— | ||
|
Kräv att ni själva får försöka bryta utfästelserna under utvärderingen, med egna försök och inte leverantörens förberedda, och att utfallet redovisas per utfästelse. |
Mäta | ||
|
Kräv besked om vad som händer när en spärr slår till: avvisas svaret, sparas försöket, får användaren veta. |
— | ||
|
Kräv en beskrivning av hur lösningen skiljer det som ska bearbetas från det som ska följas: var i anropet inhämtat material placeras, hur det märks, och vad märkningen faktiskt hindrar. |
— | ||
|
Kräv en förteckning över varje åtgärd systemet kan utföra, och att ingen av dem kan utlösas av innehåll i ett dokument utan en människas bekräftande handling. |
— | ||
|
Kräv att inhämtat material aldrig kan vidga sin egen räckvidd: ett dokument får inte kunna få systemet att hämta ett annat dokument som användaren inte får läsa. |
— | ||
|
Kräv ett prov under utvärderingen med handlingar ni själva preparerat, inklusive dold text, med utfallet redovisat per fall. |
Mäta | ||
|
Kräv att ändringar i instruktioner hanteras i samma ordning som ändringar i kod. |
— | ||
|
Kräv att resultatet följer med ändringen i historiken, så att det går att se vad som prövades och vad som släpptes igenom. |
— | ||
|
Kräv att varje fel som anmäls i drift läggs till som ett permanent fall, så att samma fel inte kan komma tillbaka obemärkt. |
— | ||
|
Kräv att skrivning sker genom samma gränssnitt och samma kontroller som en handläggares, inte förbi dem, och att leverantören redovisar vilka valideringar som därmed gäller. |
— | ||
|
Kräv att det framgår vid inmatningsfältet, i den vy där texten skrivs, vart den går, hur länge den sparas, och vem som kan läsa den. |
— | ||
|
Kräv att leverantören går igenom era användningsfall ett i taget och anger var svaret kommer ifrån: sökning i text, eller fråga mot ett system. |
— | ||
|
Kräv en förteckning över varje ställe där prompt, underlag, svar och härledda former lagras, med system, part, land och lagringstid per ställe. |
— | ||
|
Kräv att märkningen av maskinellt framtagen text följer med i utskrifter och i utlämnade handlingar och inte bara visas i gränssnittet. |
— | ||
|
Kräv att en begäran om att stänga av ett enskilt användningsfall kan lämnas av ägaren ensam, verkställs inom en avtalad tid, och inte förutsätter att hela lösningen tas ur drift. |
Avsluta | ||
|
Kräv att kopplingen annars sker med de gränssnitt systemen redan erbjuder. |
— | ||
|
Kräv att den konfiguration ni bygger upp under avtalstiden lagras som data i ett dokumenterat format, inte som inställningar vars enda uttryck är en bild av ett gränssnitt. |
— | ||
|
Kräv att svaren lämnas per användningsfall ni beskrivit och inte för produkten som helhet, eftersom en produkt kan klara en sak och inte en annan. |
— | ||
| Användar- och åtkomsthantering 21 krav · 14 kärnkrav · 0 valda Vem som kommer in, och till vad. | |||
|
Kräv att systeminstruktion och behörighetsvillkor har garanterad plats och trunkeras sist av allt, redovisat i en arkitekturbeskrivning. |
— | ||
|
Kräv att varje anrop mot ett källsystem bär den enskilda användarens identitet och prövas av källsystemet vid anropstillfället, och att ingen delad nyckel används för att nå verksamhetsdata. |
— | ||
|
Kräv att en indragen behörighet slår igenom för agentens anrop lika snabbt som för ett inloggat gränssnitt. |
Spåra | ||
|
Kräv att spåret bär den fysiska personens identitet och inte bara det konto lösningen använde för att komma fram. |
— | ||
|
Kräv att leverantören svarar per källsystem som ni räknar upp i underlaget: går det att nå med användarens egen inloggning, och om inte, vad krävs. |
Spåra | ||
|
Kräv besked om vad som händer när ett inloggningsbevis går ut mitt i ett pågående arbete: avbryts det, eller fortsätter det på en annan identitet. |
Spåra | ||
|
Kräv att arbetet med att förbereda underlaget är en egen post i anbudet, med angiven omfattning och angiven bemanning. |
— | ||
|
Kräv att varje sökning görs med den inloggade användarens behörighet, kontrollerad vid frågetillfället mot källsystemet, och att ingen delad tjänsteidentitet med bred läsrätt används för att hämta underlag. |
Spåra | ||
|
Kräv att en indragen eller ändrad behörighet slår igenom inom en tid som skrivs in i avtalet, och att tiden gäller även för underlag som redan förberetts för sökning. |
— | ||
|
Kräv en demonstration under utvärderingen där två testkonton med olika behörighet ställer samma fråga och skillnaden i hämtat underlag visas. |
Mäta | ||
|
Kräv skriftligt besked om lösningen behöver läsrätt ni inte redan gett en människa. |
— | ||
|
Kräv att indexet omfattas av samma skydd, samma kryptering och samma åtkomstbegränsning som källsystemet. |
— | ||
|
Kräv en förevisning där samma person ställer en öppen fråga mot en källa hon har läsrätt till, och att det hämtade underlaget visas, inte bara svaret. |
Mäta | ||
|
Kräv att spåret bär frågan, vilka poster som hämtades, och vilken läsrätt som gällde, så att en hämtning går att pröva mot sekretessen i efterhand. |
— | ||
|
Kräv att spåret bär rollen och inte bara identiteten, så att en post går att läsa utan att någon först utreder vem personen var vid tillfället. |
— | ||
|
Kräv att det gäller alla inställningar och inte bara instruktionstexten: val av modell, urval av underlag, trösklar och behörighetsregler. |
— | ||
|
Kräv att förvaltningsåtagandet uttrycks som namngivna moment med angiven omfattning, inte som en andel av licensen, och att det arbete ni själva förutsätts göra står i samma dokument. |
— | ||
|
Kräv besked om vad lösningen förutsätter av era gemensamma funktioner för identitet, loggning och åtkomst. |
Spåra | ||
|
Kräv att en åtgärd som ändrar ett betalningsmottagande, en adress eller en behörighet aldrig kan utlösas av innehåll i en inkommande handling. |
— | ||
|
Kräv att lösningen använder er inloggning och er katalog, och att inga konton skapas i lösningen självständigt, så att en avslutad anställning stänger den utan att någon behöver röra lösningen. |
Spåra | ||
|
Kräv att ett personligt inloggningsbevis inte kan bäras av ett program utan att det syns. |
Spåra | ||
| Informationssäkerhet 41 krav · 37 kärnkrav · 0 valda Skydd av uppgifterna, kedjan och platsen. | |||
|
Kräv att förbudet mot träning och produktförbättring gäller var och en av dem, styrkt med skriftligt intyg per part. |
— | ||
|
Kräv att varje underleverantör som kan komma åt innehållet namnges och att tillägg kräver ert skriftliga godkännande i förväg. |
— | ||
|
Kräv att en angiven driftsort är tekniskt spärrad: trafiken flyttas inte automatiskt till en annan region vid kapacitetsbrist eller avbrott. |
— | ||
|
Kräv att radering verkligen tar bort, också i säkerhetskopior, i minnesfunktioner och i sammanfattningar lösningen själv gjort av tidigare samtal. |
— | ||
|
Kräv att utförd radering bekräftas skriftligt, med uppgift om vad som togs bort. |
— | ||
|
Kräv att ni kan sätta regler per verktyg och per grupp för vad som får matas in. |
— | ||
|
Kräv besked om vad som händer vid en överträdelse: avvisas texten, varnas användaren, sparas händelsen. |
— | ||
|
Kräv att en automatisk upptäckt av personuppgifter i fritext aldrig redovisas som en spärr. |
— | ||
|
Kräv att nya AI-funktioner i en befintlig produkt levereras avstängda tills ni slår på dem. |
Avsluta | ||
|
Kräv att utfästelsen skrivs in i avtalet med påföljd, i stället för att stå i en produktbeskrivning. |
— | ||
|
Kräv uppgift om vilket bolag som driver tjänsten, i vilket land det har sitt säte, och vilken koncern som ytterst kontrollerar det. |
— | ||
|
Kräv besked om vem som innehar krypteringsnycklarna och om ni kan hålla dem själva. |
— | ||
|
Kräv en skriftlig beskrivning av vilket underlag lösningen förutsätter för att fungera: format, struktur, och den märkning den behöver för att kunna skilja gällande från ersatt. |
— | ||
|
Kräv en förteckning över vad den inte kan läsa alls, alltså inskannade handlingar utan textlager, bilder, handskrift, och innehåll som bara finns som poster i ett system. |
— | ||
|
Kräv en inventering av det tilltänkta underlaget före driftsättning: dubbletter, dokument utan angiven ägare, och dokument utan datum. |
— | ||
|
Kräv att lösningen kan använda giltighet och version som styrande villkor, så att ett dokument ni märkt som ersatt inte kan bli underlag till ett svar. |
— | ||
|
Kräv att avtalet skiljer två ansvar åt: leverantören svarar för att systemet hämtar enligt sina regler, ni svarar för att innehållet är riktigt. |
— | ||
|
Kräv att varje svar anger vilka avsnitt ur vilka dokument som användes, med version och datum, så att en handläggare kan öppna källan utan att leta själv. |
— | ||
|
Kräv att söksteget kan utvärderas skilt från svaret: för en frågeuppsättning som ni själva skriver ska leverantören redovisa hur ofta rätt underlag alls fanns bland det som hämtades. |
— | ||
|
Kräv att ni kan styra vad som görs sökbart, och att fördröjningen från ändrat dokument till ändrat svar anges i timmar eller dagar. |
— | ||
|
Kräv att uppdelningen i avsnitt är beskriven, och att ni under utvärderingen får se hur ett av era egna dokument med tabeller ser ut efteråt. |
Mäta | ||
|
Kräv att systemet svarar att underlag saknas när sökningen inte träffar, i stället för att fylla ut. |
— | ||
|
Kräv att en felaktig relation kan rättas på ett ställe, och att rättningen slår igenom i svaren inom en angiven tid. |
— | ||
|
Kräv en uppskattning av det löpande underhållet, uttryckt i arbetstimmar per år hos er och inte hos leverantören. |
— | ||
|
Kräv besked om vad som gäller medan den pågår: söker lösningen i ett halvfärdigt index, eller står den still. |
— | ||
|
Kräv att sökningen kan kombinera betydelse med ordagrann matchning, och att det visas under utvärderingen på era egna beteckningar och förkortningar. |
Mäta | ||
|
Kräv att de fall där sökning inte kan hålla avvisas i anbudet. |
— | ||
|
Kräv att lösningen känner igen frågor som kräver räkning eller fullständighet och avstår, i stället för att svara ur ett urval. |
— | ||
|
Kräv att antalet hämtade avsnitt visas för användaren tillsammans med svaret, och att inställningen är er att ändra. |
— | ||
|
Kräv att förteckningen är er att läsa utan en beställning. |
— | ||
|
Kräv att ni kan få ut vad som finns om en namngiven person från varje ställe, eller ett skriftligt besked att det stället inte kan svara på den frågan. |
— | ||
|
Kräv att en källa som görs sökbar kan begränsas till det ärende användaren arbetar i, och att en sökning över flera ärenden är ett eget beslut och inte standard. |
— | ||
|
Kräv besked om lösningen kan sammanställa uppgifter ur flera poster till ett svar som ingen av posterna visade ensam. |
— | ||
|
Kräv en förteckning över varje plats där text ur era källor lagras i härledd form, alltså index, mellanlager, cache, sparade svar och säkerhetskopior, med angiven livslängd för var och en. |
— | ||
|
Kräv att radering av en källpost tar bort samtliga härledda kopior inom en tid som anges i avtalet. |
— | ||
|
Kräv ett kvitto per raderat objekt, som går att visa för en granskare. |
Avsluta | ||
|
Fråga uttryckligen om den raderingskedjan är byggd eller bara planerad, och kräv att den förevisas: vilka lagringsplatser den når, och hur det styrks att den nått dem alla. |
— | ||
|
Kräv att radering kan begäras både för en enskild post och för ett helt underlag. |
— | ||
|
Kräv att era uppgifter aldrig används för att träna leverantörens modeller, och att allt raderas vid avtalets slut, styrkt skriftligen. |
Avsluta | ||
|
Kräv besked om vad som händer vid avtalets slut, och att avvecklingen innehåller ett fullständigt uttag före raderingen och inte efter. |
— | ||
|
Kräv besked om vilka anpassningar en offert innebär i en produkt som annars uppgraderas av någon annan, och vad varje sådan anpassning kostar vid varje kommande uppgradering. |
Avsluta | ||
| Loggning, spårbarhet och övervakning 56 krav · 3 kärnkrav · 0 valda Vad som måste gå att visa i efterhand. | |||
|
Kräv att varje maskingenererat svar i loggen går att härleda till modell, version och tidpunkt. |
Spåra | ||
|
Kräv att leveransgodkännandet skrivs som en tröskel över en fallsamling, med angiven mätmetod. |
Mäta | ||
|
Kräv redovisat vilka av era krav som inte går att visa genom ett prov, utan bara genom mätning i drift. |
Mäta | ||
|
Kräv att era prompter, testfall, konfiguration, underlag och loggar kan exporteras i öppet och dokumenterat format under avtalstiden, inte bara vid dess slut. |
Spåra | ||
|
Kräv en redovisning per behandling, alltså anrop, loggning, säkerhetskopiering, missbruksövervakning, support och utveckling, med land, ansvarig part och tillämplig lagstiftning för var och en. |
Spåra | ||
|
Kräv att ett enskilt svar kan köras om: det som loggas ska räcka för att återskapa körningen, alltså indata, inhämtat underlag och inställningar, inte bara tidpunkt och modellversion. |
Spåra | ||
|
Kräv att lösningen loggar vad som faktiskt skickades in i varje anrop, inte bara vad användaren skrev, och begär ett verkligt loggutdrag under utvärderingen. |
Mäta | ||
|
Kräv att trunkering aldrig sker tyst: utesluts underlag ska det framgå i gränssnittet och i loggen. |
Spåra | ||
|
Kräv att åtkomst till historiken hos leverantören loggas och att loggen lämnas till er på begäran. |
Spåra | ||
|
Kräv att varje driftsatt lydelse bär ett versionsnummer och att varje loggat svar bär numret på den lydelse som gällde när svaret skapades. |
Spåra | ||
|
Kräv en föreslagen lydelse, en körning mot fallsamlingen, ett dokumenterat resultat och ert godkännande innan den går i drift. |
Mäta | ||
|
Kräv en miljö där ni kan köra fallsamlingen själva, utan att beställa arbete och utan att påverka driften. |
Mäta | ||
|
Kräv att varje utfästelse om var uppgifter ligger anges per del av lösningen: lagring, index, loggar och modellanrop. |
Spåra | ||
|
Kräv att leverantörens egen åtkomst till era uppgifter godkänns av er per tillfälle, är tidsbegränsad, och loggas i en logg som lämnas till er. |
Spåra | ||
|
Kräv att detta prövas på ett stickprov ur ert eget arkiv före tilldelning, valt av er och inte av leverantören. |
Spåra | ||
|
Kräv att förteckningen skiljer original, historik, index, anrop, svar och logg, så att fem kopior inte kan döljas som en. |
Spåra | ||
|
Kräv att ett tillkommande ställe, till exempel ett nytt index eller en ny logg, anmäls innan det tar emot text. |
Spåra | ||
|
Kräv att era fall kan köras mot den driftsatta lösningen med dess verkliga underlag, inte mot en testmiljö med ett städat urval. |
Spåra | ||
|
Kräv att en körning inte skriver i verksamhetens system. |
Spåra | ||
|
Kräv att varje delsteg går att mäta för sig och redovisas för sig, så att ett tapp går att härleda till det led där det uppstod. |
Spåra | ||
|
Kräv att andelen frågor där lösningen avstod från att svara redovisas som ett eget mått, eftersom en sjunkande sådan andel är ett tidigt tecken på att systemet börjat fylla ut. |
Spåra | ||
|
Kräv att en ändring hos leverantören som kan påverka utfallet meddelas i förväg, och att ni hinner köra er samling innan den slår igenom hos er. |
Spåra | ||
|
Kräv besked om vilka av de tre åtagandena som är byggda, som en beskrivning fält för fält av vad som lagras och inte som ett ja. |
Spåra | ||
|
Kräv att en post bär personen, tidpunkten, den fullständiga inmatningen och det hämtade underlaget. |
Spåra | ||
|
Kräv att fälten hör till samma post, så att inget av dem kan saknas ensamt. |
Spåra | ||
|
Kräv att loggen inte kan ändras eller tömmas av leverantörens personal. |
Spåra | ||
|
Kräv att en läsning i loggen själv blir en post, eftersom loggen bär känsligare material än de system den hämtat ur. |
Spåra | ||
|
Kräv att lagrat material kan avgränsas och tas ut per ärende, per person och per tidsperiod. |
Spåra | ||
|
Kräv att uttaget kan göras av er själva, i ett dokumenterat och systemoberoende format, med de uppgifter som gör posten begriplig utan verktyget. |
Spåra | ||
|
Kräv att automatisk borttagning kan stängas av per uppgiftsslag, och att en genomförd borttagning bekräftas med besked om vad som togs bort och enligt vilken regel. |
Spåra | ||
|
Kräv att ett svar går att knyta till det ärendeslag där arbetet utförs, så att nyttan kan följas där den ska uppstå och inte bara i verktygets egen statistik. |
Spåra | ||
|
Kräv att leverantörens nyttosiffror åtföljs av vad som mättes, hos vem, mot vilken baslinje och under hur lång tid. |
Spåra | ||
|
Kräv att era mätdata är era, kan tas ut löpande och räcker för att ni ska kunna räkna själva i stället för att läsa en färdig sammanställning. |
Spåra | ||
|
Kräv att en enskild användning kan stängas av utan att resten av lösningen påverkas, eftersom en uppföljning utan den möjligheten inte kan leda till något. |
Spåra | ||
|
Kräv att granskningens utfall registreras som eget underlag: antal granskade, antal ändrade och antal underkända, per ärendetyp och per granskare, uttagbart av er löpande. |
Spåra | ||
|
Kräv att det underlag svaret byggde på visas i samma vy som förslaget, och att godkännandet inte kan lämnas innan det öppnats. |
Spåra | ||
|
Kräv att tiden mellan att underlaget visas och att godkännandet lämnas registreras, eftersom det är det som skiljer en läsning från ett klick. |
Spåra | ||
|
Kräv att inget svarsalternativ är förvalt, så att granskaren måste ta ställning aktivt. |
Spåra | ||
|
Kräv att urvalet till stickprov dras av lösningen efter en andel ni sätter, och att granskaren inte kan se urvalet i förväg. |
Spåra | ||
|
Kräv att ett godkännande sparas tillsammans med det underlag som visades när det lämnades, så att det i efterhand går att se vad personen faktiskt hade att gå på. |
Spåra | ||
|
Kräv att varje ändring som påverkar utfallet bär författare, tidpunkt och skäl. |
Spåra | ||
|
Kräv att leverantörens egen personal syns i samma spår som era medarbetare, med namngiven person och inte som ett driftkonto. |
Spåra | ||
|
Kräv att varje inmatning och varje svar bär tidpunkt, användare och, där det finns, ärendenummer, så att en handling går att hitta på den grund en begäran kommer. |
Spåra | ||
|
Kräv att automatisk borttagning kan stängas av per uppgiftsslag, och att den inte kan slås på igen av en produktuppdatering. |
Spåra | ||
|
Kräv att en genomförd borttagning bekräftas med vad som togs bort och enligt vilken regel, så att rensningen går att hålla mot ett gallringsbeslut. |
Spåra | ||
|
Kräv en väg att frysa material i en pågående utredning utan att stänga av lösningen, eftersom rensningen annars fortsätter i just det ni börjat undersöka. |
Avsluta | ||
|
Kräv en sökväg från verksamhetens egna identifierare till anropet, så att ärendenummer, handläggare och ett tidsintervall räcker för att hitta rätt post. |
Spåra | ||
|
Kräv att ett fall kan öppnas i sin helhet i en vy, med alla led i samma bild, och att utdraget kan tas av er själva. |
Spåra | ||
|
Kräv att samma sökning kan köras över hela materialet, så att en avgränsning inte kräver att någon läser rad för rad. |
Spåra | ||
|
Kräv en avtalad tid för leverantörens medverkan där den ändå behövs, och att tiden gäller även när den åtgärd som ska utredas inte går att ta tillbaka. |
Spåra | ||
|
Kräv att ett bevarandelås kan sättas av er och att det står över borttagningen. |
Spåra | ||
|
Kräv att lösningen levererar det en motivering behöver som egna fält: vilka källor som användes, med version och datum. |
Spåra | ||
|
Kräv att fälten också bär vilka uppgifter ur ärendet som gick in, och vilka regler eller villkor som tillämpades. |
Spåra | ||
|
Begär besked om vilket av de två som levereras, eftersom skillnaden inte syns i resultatet. |
Spåra | ||
|
Kräv att en enskilds fråga om ett beslut går att besvara utan att någon hos leverantören kopplas in. |
Spåra | ||
|
Kräv en uppdelning av vilka av era skyldigheter produkten stöder med funktion, alltså loggar, mänsklig kontroll och information till den som berörs, och vilka ni måste lösa någon annanstans. |
Spåra | ||
| Regelefterlevnad och styrning 49 krav · 47 kärnkrav · 0 valda Lagkrav, översyn och det som ska kunna förklaras. | |||
|
Kräv att svar som når någon utanför organisationen är märkta som maskingenererade. |
— | ||
|
Kräv att gränsen ritas ut i anbudet: vad som är produkt, vad som är konfiguration och vad som byggs särskilt åt er. |
— | ||
|
Kräv att det som byggs särskilt åt er levereras i en form ni kan ta över, med rätt att låta någon annan förvalta det. |
— | ||
|
Kräv en uppdelning av vilka kontroller leverantören själv utför i driften och vilka som förutsätts hos er, punkt för punkt, så att ingen kontroll hamnar i glappet mellan de två. |
— | ||
|
Kräv att utfallet av leverantörens egna kontroller redovisas löpande med resultat, och inte som ett besked att kontrollerna finns. |
— | ||
|
Kräv rätt för era revisorer och er internrevision att granska lösningen hos leverantören, med angiven svarstid och utan att granskningen blir ett uppdrag att beställa. |
— | ||
|
Kräv att en brist leverantören själv upptäcker i sina kontroller anmäls till er inom en avtalad tid, också när den redan är åtgärdad. |
— | ||
|
Kräv att avtalet namnger en beställarroll hos er som mottagare av ändringar, rapporter och besked, och en motpart hos leverantören med mandat att åta sig något. |
— | ||
|
Kräv att en ändring som påverkar vad användarna ser eller får ut godkänns av den rollen innan driftsättning. |
— | ||
|
Kräv besked om vilken roll leverantören tar och vilken den lämnar till er, uttryckt i regelverkets egna termer och inte i marknadsföringens. |
— | ||
|
Kräv den dokumentation ni behöver för att göra er egen bedömning, i tid för att göra den och inte efter driftsättning. |
— | ||
|
Kräv besked när leverantören ändrar något som kan påverka bedömningen. |
— | ||
|
Kräv besked om vilka delar av lösningen som har ett känt slut och vad som gäller när en av dem når det. |
— | ||
|
Kräv att kunskapsöverföring är en levererad del med angivet innehåll, namngivna mottagare och en tidpunkt, inte en rad i en projektplan. |
— | ||
|
Kräv dokumentation skriven för den som ska förvalta lösningen och inte för den som byggde den. |
— | ||
|
Kräv att leverantören anger vilka roller hos er och hur mycket av deras tid som förutsätts för att åtagandena ska hålla. |
— | ||
|
Kräv att leverantören räknar upp varje ändring den behöver i era system för att lösningen ska fungera, med en motivering per ändring. |
— | ||
|
Kräv att leverantören anger vilket arbete hos er som skulle behöva göras om vid ett byte, post för post. |
— | ||
|
Kräv att avvecklingsstödet har ett angivet innehåll och en angiven tid, och att det kan påkallas utan att avtalet först är i tvist. |
— | ||
|
Kräv att den godkända lösningen kan beskrivas i era arbetsuppgifter, så att en lucka går att peka ut som en uppgift och inte som ett produktnamn. |
— | ||
|
Kräv en namngiven mottagare för en begäran om att en uppgift ska gå att lösa på den godkända vägen, med angiven tid till besked. |
— | ||
|
Kräv att användningen går att läsa av per enhet och per uppgiftsslag, inte bara som ett samlat antal användare. |
— | ||
|
Kräv att avtalet upphör vid ett datum utan automatisk förlängning, och att en övergång till drift är ett nytt åtagande och inte ett fortsatt. |
— | ||
|
Kräv en skriftlig redovisning av vad som skiljer piloten från drift i full volym: vilka undantag som gäller, vad som måste byggas om, och vad det kostar. |
— | ||
|
Kräv att redovisningen lämnas före start, eftersom den vid utvärderingen blir ett argument i stället för ett underlag. |
Mäta | ||
|
Kräv att mätningen görs på fall ni själva valt ut. |
Mäta | ||
|
Kräv besked, per regel ni ställer upp, om den är byggd som ett villkor i lösningen eller som en anmodan till användaren. |
— | ||
|
Kräv att en funktion ni inte godkänt går att hålla otillgänglig med en inställning ni själva råder över, och att inställningen inte kan sättas ur spel av en produktuppdatering. |
— | ||
|
Kräv en läsbar förteckning över vad som är påslaget för vilka grupper, tillgänglig för er när som helst och inte på begäran. |
— | ||
|
Kräv att aktivering av en ny förmåga skrivs till ett spår med vem, när och för vilka. |
— | ||
|
Kräv att er egen nivå för användningen står i förfrågan och att anbudet svarar mot den. |
— | ||
|
Kräv att en passerad gräns har en avtalad följd med angiven tid, och godta inte ett åtagande att förbättra som enda följd. |
— | ||
|
Kräv att lösningen kan sättas strängare för ett användningsslag än för ett annat i samma installation, så att en beslutad skillnad i riskvilja går att genomföra utan ny upphandling. |
— | ||
|
Kräv besked om vilka poster som är uppsägningsbara och vilka som binder er för hela perioden, eftersom det som inte går att säga upp är vad ett byte kostar. |
— | ||
|
Kräv att kalkylens poster följs upp mot verkligt utfall vid en avtalad tidpunkt, en post i taget, och att avvikelsen redovisas skriftligt. |
— | ||
|
Kräv angivet vilka ärendeslag lösningen är prövad mot, och vilka den inte är prövad mot. |
— | ||
|
Kräv att ett anmält fel går att märka med ärendeslag, så att en invändning blir ett tal och inte ett intryck. |
— | ||
|
Kräv att varje utfästelse åtföljs av hur den visas, i samma svar som utfästelsen. |
— | ||
|
Kräv en förevisning i stället för ett ja där saken går att visa, med era exempel och inte leverantörens. |
Mäta | ||
|
Kräv besked om vilka av era krav som är uppfyllda i det som finns nu och vilka som förutsätter ett bygge, med vem som bygger och när. |
— | ||
|
Kräv att det som inte kan visas före tilldelning blir ett åtagande med tidpunkt. |
— | ||
|
Kräv att leverantören anger vilka regelverk lösningen är byggd för att uppfylla, och vilka den inte rör. |
— | ||
|
Kräv besked om vilka av era skyldigheter leverantören tar på sig och vilka som stannar hos er. |
— | ||
|
Kräv att ett åtagande om efterlevnad anger vilken skyldighet det gäller, i stället för att lösningen följer gällande rätt. |
— | ||
|
Kräv en beskrivning av vad lösningen gör i verksamhetens termer, konkret nog att den går att pröva mot en bestämmelse. |
— | ||
|
Kräv angivet vilka moment i handläggningen lösningen deltar i, och vad den avgör respektive föreslår. |
— | ||
|
Kräv att ni själva kan ta fram allt som rör ett enskilt ärende, utan att beställa ett utdrag. |
— | ||
|
Kräv angiven ledtid för det ni ändå måste beställa, och att den ligger inom era frister. |
— | ||
|
Kräv att leverantören underrättar er när en myndighet begär uppgifter direkt av den, i den mån lagen tillåter. |
— | ||
| AI- och modellhantering 37 krav · 2 kärnkrav · 0 valda Vilken modell, var den körs, och vad ett byte betyder. | |||
|
Kräv att leverantören skriftligen anger vilken modell lösningen använder och var den körs, och att ett byte är en avtalad ändring som meddelas i förväg. |
Byta | ||
|
Kräv att det står vilken version, så att namnet inte tyst kan peka på en annan modell. |
Byta | ||
|
Kräv besked om vad lösningen gör när den inte kan svara: gissar den, avstår den, eller lämnar den över till en människa. |
Byta | ||
|
Kräv att varje anmält fel besvaras med en klassning, bugg eller avvikelse, och på vilken grund. |
Byta | ||
|
Kräv angivet vilka steg som på er begäran kan göras deterministiska. |
Byta | ||
|
Kräv en jämförelse under utvärderingen: samma uppgift körd på minst två storlekar. |
Mäta | ||
|
Kräv kvalitet, svarstid och förbrukning per svar redovisade bredvid varandra, så att ni ser vad det dyrare alternativet ger. |
Mäta | ||
|
Kräv svarstid som utfäst servicenivå, angiven både som medianen och som den långsammaste tiondelen, uppmätt vid den samtidiga belastning ni beskriver. |
Byta | ||
|
Kräv att era egna prov får köras om före varje byte, och att lösningen kan hålla två alternativ igång parallellt under en sådan jämförelse. |
Byta | ||
|
Kräv att leverantören namnger varje part i kedjan som får se era in- och utdata. |
Byta | ||
|
Kräv separata besked om mänsklig granskning och missbruksövervakning: sker det, av vem, i vilket land, och hur länge sparas materialet. |
Byta | ||
|
Kräv att ett nytt led i kedjan kräver ert godkännande i förväg och att inställningen inte kan ändras ensidigt. |
Byta | ||
|
Kräv att leverantören redovisar i skrift hur spärren är satt för just ert avtal. |
Byta | ||
|
Kräv att den går att kontrollera om under avtalstiden, i stället för att intygas en gång vid signering. |
Byta | ||
|
Kräv att en angiven källhänvisning kontrolleras maskinellt mot att källan finns och innehåller det som påstås. |
Byta | ||
|
Kräv att svaret annars märks som overifierat, eftersom en påhittad hänvisning ser ut precis som en äkta. |
Byta | ||
|
Kräv en anmälningsfunktion i samma vy som svaret visas, där det anmälda svaret bevaras oförändrat tillsammans med det underlag det byggde på. |
Byta | ||
|
Kräv en avtalad stickprovsgranskning: ett bestämt antal svar per ärendetyp och månad granskas av er, andelen felaktiga redovisas, och en överenskommen nivå utlöser åtgärd hos leverantören. |
Byta | ||
|
Kräv skriftlig motivering innan finjustering genomförs: vilket mätbart problem den löser, vad som prövats i stället, och vilken förbättring som väntas, mätt på en uppgiftsuppsättning ni själva känner till. |
Byta | ||
|
Kräv en dokumenterad förteckning över vad som ingick i träningen, vem som godkände det och när, eftersom en felaktig uppgift bara kan åtgärdas genom omträning från en känd utgångspunkt. |
Byta | ||
|
Kräv en skriftlig förteckning över vad som är flyttbart och vad som inte är det, med format angivet för varje del. |
Byta | ||
|
Kräv angivet vilka delar av lösningen som är byggda mot en enskild modell och vad som måste göras om vid ett byte, uttryckt i arbetstid. |
Byta | ||
|
Kräv angiven uppsägningstid och angivet avvecklingsstöd, och angivet vad som händer med lösningen om modellen slutar tillhandahållas. |
Byta | ||
|
Kräv att ni under utvärderingen får se konfigurationen som visar spärren. |
Mäta | ||
|
Kräv ett åtagande att underrätta er, i den mån lagen tillåter, när en utländsk myndighet begär åtkomst, samt en löpande redovisning av antalet sådana begäranden. |
Byta | ||
|
Kräv att varje svar prövas mot schemat innan det når mottagarsystemet och att prövningen sker utanför modellen. |
Byta | ||
|
Kräv en förteckning över varje begränsning leverantören utfäster, och för var och en ett besked om den är byggd som instruktion eller som spärr utanför modellen. |
Byta | ||
|
Kräv att varje utfästelse ni betraktar som ett krav håller även om modellen försöker göra tvärtom. |
Byta | ||
|
Kräv besked om var prövningen av ett anrop sker, och att den sker i det utförande ledet och inte som en instruktion till modellen. |
Byta | ||
|
Kräv en ritning över kedjan: varje steg, vad det tar emot, vad det lämnar, och vilka av stegen som är modeller. |
Byta | ||
|
Kräv besked om vilken modell som skapar vektorerna, var den körs, och vem som driver indexet. |
Byta | ||
|
Kräv att ett byte av den modellen meddelas i förväg och behandlas som en avtalad ändring. |
Byta | ||
|
Kräv att posten också bär versionerna av modell och instruktion samt det levererade svaret. |
Byta | ||
|
Kräv att fälten hämtas ur det som styrde svaret och inte formuleras av modellen i efterhand. |
Byta | ||
|
Kräv redovisat vad lösningen vilar på när en generell modell ingår, så att ni vet vad ni för vidare. |
Byta | ||
|
Kräv av de leverantörer ni redan har skriftligt besked om produkten skickar innehåll till en språkmodell, till vem, och om funktionen är påslagen. |
Byta | ||
|
Kräv angivet vad ett byte av modell inuti lösningen kräver av er i arbetstid. |
Byta | ||
| Integration och API:er 34 krav · 2 kärnkrav · 0 valda Verktyg, agenter och kopplingen till era system. | |||
|
Kräv att argumenten prövas mot ett schema och mot användarens pågående ärende innan anropet körs. |
Byta | ||
|
Kräv att varje utfört anrop skrivs till ett spår som lösningen själv inte kan ändra i efterhand. |
Byta | ||
|
Kräv att spåret skrivs innan resultatet lämnas tillbaka, så att ett anrop som inte går att spåra stoppas i stället för att släppas igenom. |
Byta | ||
|
Kräv att posten bär begäran som den såg ut, vilket konto som körde den, och utfallet. |
Byta | ||
|
Kräv att en enskild förmåga kan stängas av av er, samma dag, utan att lösningen byggs om. |
Byta | ||
|
Kräv en förteckning per agent över uppdraget, verktygen och de system verktygen når, i klartext och inte som produktbeskrivning. |
Byta | ||
|
Kräv att leverantören redovisar hur stor del av anropet verktygsbeskrivningarna upptar vid den konfiguration ni köper, och hur den andelen växer när ett verktyg läggs till. |
Byta | ||
|
Kräv ett tak som ni sätter för antalet steg och för hur länge en agent får arbeta, samt besked om vad som händer när taket nås. |
Byta | ||
|
Kräv att stegen går att följa i efterhand som en sekvens: verktyg, argument och resultat i tur och ordning. |
Byta | ||
|
Kräv att ett enskilt verktyg kan stängas av per agent. |
Byta | ||
|
Kräv att kopplingen kan användas av en annan klient än leverantörens egen, och att det visas under utvärderingen. |
Mäta | ||
|
Kräv en versionerad förteckning över varje exponerad förmåga, vad den läser, vad den ändrar och vilka klienter som kan nå den. |
Byta | ||
|
Kräv att leverantören namnger varje ställe där det inte går, med skälet och med vad som gäller där i stället. |
Byta | ||
|
Kräv en förevisning under utvärderingen där två användare med olika rätt ger agenten samma uppdrag och skillnaden i vad agenten lyckades utföra visas. |
Mäta | ||
|
Kräv att ritningen stämmer med det som körs och att den kan hållas mot en verklig körning. |
Byta | ||
|
Kräv att ett enskilt ärende går att öppna som en kedja i en vy, med varje mellansteg bevarat. |
Byta | ||
|
Kräv att den som granskar kan jämföra det första underlaget med det sista svaret utan att beställa ett utdrag. |
Byta | ||
|
Kräv att de uppgifter som ska följa med oförändrade bärs som egna fält genom kedjan och prövas mot källan i sista steget. |
Byta | ||
|
Kräv att en avbruten kedja lämnar ett tydligt utfall och inte ett halvfärdigt resultat som ser färdigt ut. |
Byta | ||
|
Kräv en förteckning över varje åtgärd agenten kan utföra, sorterad efter om verkan går att återta. |
Byta | ||
|
Kräv att det som inte går att återta är spärrat i rättigheterna hos det system som utför åtgärden, inte i lösningens egen logik. |
Byta | ||
|
Kräv att spärren visas under utvärderingen genom att ni själva ber agenten göra det förbjudna och ser var den stoppas. |
Mäta | ||
|
Kräv att ett godkännandesteg visar den verkliga åtgärden och dess mottagare, hämtad ur mottagarsystemet och inte formulerad av agenten. |
Byta | ||
|
Kräv att antalet godkännandefrågor per ärende redovisas löpande i drift, eftersom en stigande siffra är det tidigaste tecknet på att steget slutat vara ett skydd. |
Byta | ||
|
Kräv en namngiven förteckning över de autentiseringsmetoder inkopplingen stöder, och kräv den före tilldelning och inte vid leverans. |
Byta | ||
|
Kräv att varje svar som lyder att det går att lösa åtföljs av vem som bygger, vad det kostar och när det finns. |
Byta | ||
|
Kräv att listan över utgående adresser sätts av er, med förvald hållning att inget är tillåtet. |
Byta | ||
|
Kräv en märkning av maskinskrivna poster som lever i mottagarsystemet och inte bara i AI-verktygets egna uppgifter. |
Byta | ||
|
Kräv en beskriven och prövad återställning: en omgång ska gå att peka ut och ta tillbaka, och tiden det tar ska anges. |
Byta | ||
|
Kräv att det provkörs under utvärderingen, i en miljö som liknar er, genom att en felaktig omgång skrivs och tas tillbaka. |
Mäta | ||
|
Kräv besked om vem som svarar när felet visar sig i verksamhetssystemet, för den frågan hamnar annars mellan två leverantörer. |
Byta | ||
|
Kräv att varje relation bär sitt ursprung: registrerad av en människa, hämtad ur ett angivet källsystem, eller utvunnen av en modell ur en angiven text. |
Byta | ||
|
Kräv att era källsystem kan skilja en läsning gjord genom ett programgränssnitt från en läsning en människa gjort i gränssnittet, och visa dem var för sig. |
Byta | ||
|
Kräv att åtkomst kan spärras per klient utan att personen spärras, så att en integration kan stängas av utan att någon förlorar sitt arbete. |
Byta | ||
| Dataportabilitet och exit 11 krav · 2 kärnkrav · 0 valda Att kunna lämna, ta med sig och återställa. | |||
|
Kräv att träningsdatan och den finjusterade modellen är era, att de inte används åt någon annan kund, och att båda kan lämnas ut till er eller raderas på er begäran. |
Avsluta | ||
|
Kräv att uttaget kan göras av er utan leverantörens medverkan. |
Byta | ||
|
Kräv att den redovisningen är tillgänglig för er löpande, i en form ni kan exportera, och inte bara i leverantörens egen instrumentpanel. |
Byta | ||
|
Kräv att hela historiken av tidigare lydelser bevaras och kan lämnas ut till er, inte bara den aktuella. |
Byta | ||
|
Kräv att fallen och deras förväntade svar tillhör er och kan exporteras. |
Byta | ||
|
Kräv att förmågorna erbjuds enligt ett öppet protokoll och att beskrivningen av dem tillhör er och kan lämnas ut i sin helhet. |
Byta | ||
|
Kräv besked om vad som händer med kopplingen när avtalet upphör: fortsätter den fungera utan leverantören, och vem driftar den då. |
Byta | ||
|
Kräv att märkningen görs av er, utan leverantörens medverkan. |
Byta | ||
|
Kräv att beskrivningen av saker och samband tillhör er och kan exporteras i ett öppet format. Den är det ni betalat för, och det som blir kvar när verktyget byts. |
Byta | ||
|
Kräv att posten skrivs innan svaret lämnas ut. |
Byta | ||
|
Kräv att allt på er sida av gränsen går att läsa och ändra utan leverantörens medverkan, och att en ändring där inte kräver ett nytt uppdrag. |
Byta | ||
| Drift, support och dokumentation 30 krav · 29 kärnkrav · 0 valda Förvaltning, tillgänglighet och det som ska hålla över tid. | |||
|
Kräv att uppföljningen levereras till verksamhetens ägare och inte bara till den tekniska förvaltningen. |
— | ||
|
Kräv att era egna medarbetare utför de moment som ska kunna utföras i förvaltningen, redan under utvärderingen, med leverantören som åskådare och inte som utförare. |
Mäta | ||
|
Kräv att varje anbud anger vad lösningen förutsätter av er löpande, uttryckt i roller och arbetstid per period. |
— | ||
|
Kräv besked om vilka av era befintliga produkter som redan innehåller en motsvarande funktion. |
— | ||
|
Kräv av en leverantör ni redan har besked om hur det som erbjuds förhåller sig till det ni betalar för. |
— | ||
|
Kräv att åtagandena besvaras mot era frågor i er ordning, så att två anbud går att lägga bredvid varandra. |
— | ||
|
Kräv att en bekräftelse går ut på en kanal mottagaren registrerat i förväg, och inte på den kanal begäran kom in på. |
— | ||
|
Kräv att ingen tröskel, urvalsgräns eller spärr sätts utan en angiven mätmetod ni kan köra själva. En kalibrering ni inte kan upprepa är en inställning ni inte äger. |
Mäta | ||
|
Kräv att ett byte av en utbytbar del genomförs minst en gång under avtalstiden som en övning, med utfallet redovisat, eftersom ett bytesstöd som aldrig prövats är ett påstående. |
— | ||
|
Kräv besked om vad som förfaller vid ett sådant byte: vilka mätvärden som inte längre gäller, vilka prov som måste köras om, och vem som betalar det arbetet. |
— | ||
|
Kräv att spåret levereras löpande till er mottagare i ett format ni angett, och inte enbart går att titta på hos leverantören. |
— | ||
|
Kräv att underlag hämtas genom er befintliga åtkomstväg i stället för genom en egen kopia av materialet. |
— | ||
|
Kräv att anbudet innehåller en avvikelselista mot era anslutningskrav, punkt för punkt, med skäl. |
— | ||
|
Kräv en förteckning, upprättad vid införandet och underhållen, över vad som kommer att peka på lösningen i drift. |
— | ||
|
Kräv att den anger vilka system som tar emot dess utdata, vilka rutiner som hänvisar till den, och vilka konton den håller. |
— | ||
|
Kräv att uttaget av det som ska bevaras provkörs en gång medan avtalet löper, så att ni vet att det fungerar innan ni behöver det. |
— | ||
|
Kräv besked om vad som slutar fungera hos er när lösningen stängs av: vilka flöden stannar, vilka konton blir overksamma, vilket arbete faller tillbaka på en handläggare. |
— | ||
|
Kräv att era mätdata från hela driftperioden lämnas samlade vid avvecklingen, eftersom de är underlaget för att bedöma nästa lösning av samma slag. |
— | ||
|
Kräv att den godkända lösningen är åtkomlig för alla som har uppgiften, utan ansökan per person. |
— | ||
|
Kräv en beskrivning av vad lösningen inte klarar, uttryckt i era arbetsuppgifter, så att ni vet var luckorna ligger. |
— | ||
|
Kräv att leverantören själv anger vilken av era nivåer lösningen faller i, prövad mot era tre frågor, och att svaret är bindande. |
— | ||
|
Kräv att nivån är en avtalad gräns och inte en beskrivning. |
— | ||
|
Kräv att en produktuppdatering som ger lösningen skrivrätt eller en ny mottagare hanteras som ett avtalsbrott och inte som en nyhet. |
— | ||
|
Kräv att svaren lämnas på era frågor i er ordning, så att två anbud går att lägga bredvid varandra utan att först skrivas om. |
— | ||
|
Kräv besked om vilka delar av lösningen som kan stängas av för att hålla den kvar på den nivå ni köpt. |
— | ||
|
Kräv att bevis som ges till program har kort giltighet och kan återkallas ett i taget. |
— | ||
|
Kräv att en avslutad anställning stänger de kopplingar kontot bar, och att de går att förteckna innan kontot stängs. |
— | ||
|
Kräv att lösningen kan köras vidare på en fryst version medan ni prövar en ny. |
— | ||
|
Kräv att det underlag och de fall ni arbetat fram lämnas i ett format som överlever ett byte av lösning. |
— | ||
|
Kräv att en anslutning som byggs en gång kan användas av era övriga lösningar utan ny avgift per lösning. |
— | ||
| Kommersiella villkor 20 krav · 3 kärnkrav · 0 valda Pris, avtal och det som kostar att kräva. | |||
|
Kräv att modellvalet är en inställning ni styr per användningsfall, inte något inbyggt i lösningen, och att leverantören anger ledtid och kostnad för att lägga till ett alternativ. |
Byta | ||
|
Kräv angivet pris och angiven ledtid för en omträning, och angivet vad som gäller när leverantören byter ut grundmodellen under er. |
Byta | ||
|
Kräv licensvillkoren för den modell som används, redovisade mot er avsedda användning. |
Byta | ||
|
Kräv redovisad tokenförbrukning per användningsfall och tidsperiod, inte ett klumpat månadspris. |
Byta | ||
|
Kräv att ett prisförslag anger antaganden om förbrukning, så att avtalet går att följa upp mot verkligheten. |
Byta | ||
|
Kräv att in- och utvolym redovisas separat, per arbetsflöde och per anrop, så att ni ser vilken sida som driver kostnaden. |
Byta | ||
|
Kräv att anbudspriset räknas på ett scenario ni beskriver, med angiven storlek på underlaget, så att två anbud går att jämföra med varandra. |
Byta | ||
|
Kräv besked om vad som händer med tid och pris när materialet visar sig vara sämre än antaget. |
Byta | ||
|
Kräv angiven ledtid och angivet pris för en fullständig omindexering av er volym. |
Byta | ||
|
Kräv angivet pris och angiven ledtid för de ändringar som med säkerhet kommer: ett nytt källsystem, en omskriven handläggningsrutin, ett byte av modell. |
Byta | ||
|
Kräv att prisjusteringen är känd i förväg och att poster som växer med användningen har ett tak ni satt. |
Byta | ||
|
Kräv att avvecklingen är prissatt i samma offert som piloten: vad avstängningen kostar, vad som händer med data och konton, och hur lång tid det tar. |
Avsluta | ||
|
Kräv besked om vilken felnivå priset förutsätter, eftersom ett lägre pris kan vara en lägre nivå och inte en effektivare lösning. |
Byta | ||
|
Kräv att engångsposter och löpande poster redovisas skilda från varandra, med angiven period för varje löpande post, så att ett lågt införandepris inte bärs av ett förvaltningspris ni upptäcker senare. |
Byta | ||
|
Kräv en förteckning över de poster lösningen förutsätter men leverantören inte levererar, alltså licenser, drift och tjänster hos tredje part som ni betalar direkt. |
Byta | ||
|
Kräv att åtagandena om svarstid, kvalitetsnivå och kostnadstak gäller funktionen och inte en namngiven beståndsdel, så att de består när leverantören byter något inuti. |
Byta | ||
|
Kräv angivet pris per tillkommande användare och angiven tid för att komma igång: en licensmodell som gör varje ny användare till ett beslut bygger in tröskeln i avtalet. |
Mäta | ||
|
Kräv att anslutningen till era gemensamma funktioner prissätts som en egen post, skild från lösningens övriga pris, så att kostnaden för det gemensamma syns och inte försvinner i ett totalpris. |
Byta | ||
|
Kräv att en lösning som erbjuder en egen variant av något ni redan äger prissätter både varianten och anslutningen till er befintliga. |
Byta | ||
|
Kräv angivet pris för att ansluta ett tillkommande verksamhetsområde till en lösning i drift, så att den andra användaren inte betalar ett nytt införande. |
Byta | ||
| Inte i specen 34 krav · 0 kärnkrav · 0 valda Instruktion till er, inte till anbudsgivaren. | |||
|
Godta inte ett prov som förutsätter ett bestämt rätt svar per rad. Ett sådant prov kan varken gå igenom eller falla på ett sätt som betyder något. |
— | ||
|
Kräv att varje utfäst begränsning placeras på ett av de fyra stegen, i en förteckning som går att läsa utan att någon öppnar koden. |
— | ||
|
Kräv en skriftlig motivering när en begränsning ligger på prompttext, med besked om vad som hindrar att den flyttas uppåt. |
— | ||
|
Kräv att en begränsning som flyttas nedåt under bygget anmäls till dig, så att en förenkling i genomförandet inte tyst byter ut mekanik mot en mening. |
— | ||
|
Kräv att en modell som granskar en annan modells svar redovisas som det den är, en bedömning med egen spridning, och aldrig som en kontroll. |
Byta | ||
|
Kräv att varje resultat som läggs fram anger antalet körningar per fall och spridningen mellan dem, och behandla en siffra utan de uppgifterna som ett enskilt utfall. |
— | ||
|
Kräv att resultatet redovisas per fall och inte bara som ett samlat mått, så att ett fall som alltid faller går att skilja från ett som faller ibland. |
— | ||
|
Kräv att en förevisning aldrig ersätter en mätning: det som visas i ett möte är ett utfall, valt av den som visar. |
Mäta | ||
|
Kräv att fallsamlingen och körningarnas rådata tillhör er och kan köras om av er själva, utan att någon bokas in. |
Mäta | ||
|
Kräv att varje funktion som ska godkännas lämnas som den text, det tröskelvärde eller det villkor som faktiskt styr beteendet, i klartext och med versionsbeteckning. |
Mäta | ||
|
Kräv att godkännandet registreras mot den versionen, så att det i efterhand går att se vilken lydelse som var godkänd när ett visst svar lämnades. |
— | ||
|
Kräv att en ändrad lydelse kräver ett nytt godkännande, även när ändringen beskrivs som en justering. |
— | ||
|
Kräv att förslaget åtföljs av vad ändringen väntas göra och av utfallet mot fallsamlingen, så att godkännandet vilar på något prövbart. |
Mäta | ||
|
Kräv att varje ändring i instruktioner, tröskelvärden och urvalsregler går att ta tillbaka var för sig, utan att andra ändringar följer med. |
Mäta | ||
|
Kräv att mätningen mot fallsamlingen körs mellan två ändringar och inte efter en bunt, och att resultatet följer med ändringen i historiken. |
Mäta | ||
|
Kräv att stoppregeln står skriven före körningen, med angivet mått och angiven gräns, så att beslutet inte fattas på det resultat som råkade komma. |
— | ||
|
Kräv besked om vilka ändringar som inte går att ta tillbaka, eftersom de kräver ett annat arbetssätt än det här. |
— | ||
|
Kräv att fallen och deras rätta svar formuleras av er, och att leverantörens roll är att köra samlingen och redovisa utfallet. |
— | ||
|
Kräv besked om vilka fall som härletts ur systemets egna svar, eftersom de mäter oförändrat beteende och inte riktighet. |
— | ||
|
Kräv att samlingen kan läsas och ändras av ägaren utan teknisk medverkan, och att en ändring är versionerad så att två mätningar går att jämföra. |
Mäta | ||
|
Kräv att varje redovisad mätning anger vilken version av samlingen den kördes mot. |
Mäta | ||
|
Kräv att samlingen är er egendom och kan tas ut i sin helhet. |
— | ||
|
Kräv att lösningen skiljer på vad som ändras av verksamheten och vad som ändras av den som bygger, och att den första gruppen går att ändra utan ett uppdrag. |
— | ||
|
Kräv att varje ändring bär vem som beslutade den och inom vilket område, så att ett beslut i efterhand går att knyta till någon som kunde fatta det. |
— | ||
|
Kräv att den som äger innehållet får en miljö där en ändring kan prövas mot fallsamlingen innan den går i drift. |
Mäta | ||
|
Kräv besked om vilka beslut som förutsätter kunskap ni inte har hos er, eftersom de annars fattas av leverantören under namnet samråd. |
— | ||
|
Kräv att avvisade och återtagna lösningar dokumenteras på samma ställe som de genomförda, med vad som mättes och vad som avgjorde. |
— | ||
|
Kräv att anteckningen anger vilka förutsättningar utfallet vilade på, så att den går att ompröva när en förutsättning har ändrats. |
— | ||
|
Kräv att materialet tillhör er och lämnas över i läsbart skick när uppdraget slutar, eftersom det annars stannar hos dem som var med. |
— | ||
|
Kräv att ett föreslaget angreppssätt prövas mot det som redan prövats, och att svaret ingår i förslaget. |
— | ||
|
Kräv ett mätt utgångsläge på den befintliga lösningen innan en ombyggnad påbörjas, och att samma fallsamling används för båda mätningarna. |
Mäta | ||
|
Kräv att en ombyggnad som mäter lägre än det den ersatte redovisas som det, och att den tidigare lösningen går att återta utan ett nytt uppdrag. |
— | ||
|
Kräv att varje skärpning av en instruktion mäts mot hela fallsamlingen och inte bara mot det fall den skulle rätta. |
Mäta | ||
|
Kräv besked om vilka mätvärden en föreslagen ändring väntas röra åt fel håll, lämnat före ändringen och inte efter. |
— | ||
Så använder ni urvalet
- Välj familj, ev. bara kärnkrav i det visade, och kryssa det som gäller den här affären. En not på raden följer med i exporten.
- Kopiera markdown. Klistra in i en chatt tillsammans med prompten. Skriv först vad ni ska köpa, för vem, och i vilken miljö.
- Nästa steg, inte den här ytan: en MCP mot samma poster, med prompten som skill. Då läser agenten kartan live när den uppdateras.
Du hjälper en beställare att skriva en kort kravspec för en AI-upphandling.
Du får ett urval poster ur Kunskapskartan om AI. Varje post har id, text, begrepp, familj och ibland en kommentar från beställaren. Det är ett urvalsunderlag, inte en spec. Er uppgift är att korta, inte att lägga till.
Beställaren skriver först, i en till tre meningar: vad som ska köpas eller byggas, för vem, och ungefär i vilken miljö.
Arbeta så här:
1. Korta genom urval. Hitta inte på krav som saknas i underlaget.
2. Behåll kartans id på varje krav som blir kvar, så det går att spåra tillbaka till begreppet.
3. Flera rader som säger samma sak blir en. Behåll den skarpaste lydelsen och dess id.
4. Täck de fyra familjerna mäta, spåra, avsluta och byta om det här är en AI-lösning i drift. Saknas en familj: säg det, och peka på närmaste id i urvalet. Hitta inte på ett nytt krav.
5. Poster som vilar på beställaren är inte ska-krav på leverantören. Flytta dem till förutsättningar ni själva måste namnge.
6. Varje krav som blir kvar får tre rader under sig: Hur det visas. Av vem. När (utvärdering / leverans / drift). Saknas visning, stryk eller skriv om från den befintliga texten.
7. Sikta under tolv krav. Över fyrtio är för långt. Hellre få krav som går att följa upp, plus att anbud utvärderas på hur leverantören faktiskt svarar.
Svara med:
- Upphandlingen, återgiven
- Vilka av de fyra familjerna som täcks, och vilka som saknas
- Kravlistan, med id, lydelse och visning
- Förutsättningar hos er
- Vad som lämnades utanför, och varför
- Det ni fortfarande måste besluta innan listan lämnar huset