Læringssti 06Lektion 3 / 6

Bed en leverandør om dokumentation

Omsæt leverandørpåstande til spørgsmål, der kan testes. Kontrollér omfang, konfiguration, kontraktvilkår og det ansvar, din organisation beholder.

Praktisk10 minReviewet

Udgivet af Sådan skriver vi

Det lærer du

  • Skeln mellem en produktpåstand og dokumentation for den krævede adfærd.
  • Design en evaluering med dit eget scenarie og dine egne acceptkriterier.
  • Registrér uafklarede krav uden at behandle dem som bekræftede funktioner.

Start med dit krav

En leverandør kan demonstrere imponerende output uden at besvare dit vigtigste spørgsmål. Definér kravet før demonstrationen.

Overvej en fiktiv virksomhed med fortrolige kontraktdata. Teamet har brug for AI-assisteret vedligeholdelse af en eksisterende applikation. Leverandøren viser en ny applikation bygget fra et tomt repository. Resultatet demonstrerer en evne, men tester ikke virksomhedens vedligeholdelsesproces.

Forbered et lille, repræsentativt repository med godkendte syntetiske data. Medtag én eksisterende konvention, én fejlslagen test og én ændring, der kræver en menneskelig beslutning. Giv hver leverandør de samme acceptkriterier.

Bed om både adfærd og dokumentation

KravDokumentation, der skal indhentesSpørgsmål, der skal afklares
DatabehandlingBeskrivelse af datastrømme, aktuelle vilkår og relevant konfigurationHvilke kopier sendes til hvilke tjenester?
Agentens bemyndigelseRettighedsmodel og demonstration af en afvist handlingHvor håndhæves grænsen?
LeverancePlan, diff, kontroller og en resulterende pull requestKan en reviewer spore kravet?
Menneskelige beslutningerEn blokeret arbejdsgang og registreringen af dens afklaringHvem kan godkende næste trin?
DriftAnsvarsfordeling og hændelsesprocedureHvem reagerer, når tjenesten fejler?
ExitEn prøveeksport og et uafhængigt rebuildHvad kan stadig bruges, når adgangen ophører?

Et udsagn som »understøtter SSO« kræver kontekst. Spørg, hvilke identitetsudbydere, kontoniveauer, roller og adfærd ved fjernelse af brugere der er inkluderet. Test den relevante adgangsændring.

Ved erklæringer eller certificeringer skal du undersøge omfang, dækket tjeneste, reviewperiode og undtagelser. Antag ikke, at leverandørens erklæring automatisk dækker de applikationer, dit team bygger.

Observer et vanskeligt tilfælde

Bed leverandøren om at vise, hvad der sker, når en krævet kontrol fejler. Undersøg derefter det resulterende artefakt og beslutningsforløbet. Et nyttigt system gør ufuldstændigt arbejde og manglende dokumentation synlig.

Tilføj for kontraktapplikationen en fiktiv anmodning, der krydser en adgangsgrænse. Evalueringen skal vise, hvordan systemet håndterer kravet, og hvordan en reviewer verificerer resultatet. Brug ikke rigtige fortrolige data for at gøre demonstrationen mere realistisk.

Registrér forskelle mellem den demonstrerede konfiguration og det foreslåede køb. En lovet fremtidig funktion er en afhængighed, ikke en leveret evne.

Bevar et dokumentationsregister

Registrér for hvert krav et link til dokumentationen, dato, konfiguration, reviewer og konklusion. Brug klare tilstande: verificeret for dette scenarie, uafklaret eller uden for omfanget.

Udpeg en ansvarlig og en frist for uafklarede punkter. Afgør, om hvert punkt blokerer beslutningen, kræver en kontraktlig betingelse eller kan accepteres med en dokumenteret begrænsning.

Anvend samme kriterier på Taiga. Den offentlige dokumentation og Trust Centre giver udgangspunkter. Bekræft, at den valgte ordning opfylder dine krav. Fortsæt med exit og portabilitet.

Lav øvelsen

En fiktiv leverandør siger, at dens AI-udviklingsprodukt er klar til enterprise-brug. Vælg tre krav fra tabellen. Skriv for hvert krav en test, bed om et artefakt, udpeg en reviewer, og definér konsekvensen af et manglende svar.

Download arbejdsark (Markdown)

Kontrollér din forståelse

En leverandør demonstrerer et sikkert eksempelmiljø. Hvad bør evalueringen afklare derefter?

Kilder og videre læsning