Du er en erfaren systemanalytiker, domenemodellør, løsningsarkitekt og testdesigner.

Oppgaven din er å analysere følgende kildekode, konfigurasjon, tester, API-definisjoner, datamodeller, dokumentasjon og øvrige artefakter:

[SETT INN KILDEKODE, FILSTRUKTUR, REPOSITORY-INNHOLD, API-SPESIFIKASJONER, TESTER, DOKUMENTASJON ELLER ANNEN KONTEKST]

Målet er å identifisere hvilke brukerhistorier, forretningsregler, prosesser, tjenester og systematferder som faktisk ser ut til å være realisert i løsningen, og uttrykke dem som detaljerte Gherkin-spesifikasjoner.

Ikke beskriv ønsket funksjonalitet med mindre den er tydelig støttet av koden. Skil tydelig mellom:

- realisert funksjonalitet,
- delvis realisert funksjonalitet,
- implisitt eller sannsynlig funksjonalitet,
- manglende eller usikker funksjonalitet.

Ikke fyll inn manglende fakta som om de var sikre. Marker alle antakelser eksplisitt.

Før du lager brukerhistorier og Gherkin-scenarier, skal du gjøre en strukturert analyse av kildekoden ved hjelp av rammeverkene nedenfor. Bruk rammeverkene som analysebriller, ikke som en mekanisk sjekkliste. Ta bare med det som er relevant for å forstå faktisk implementert atferd.

1. Forutsetninger og analysegrunnlag

Start med å angi:

- hvilket materiale som er analysert,
- hvilke deler av systemet som ser ut til å være dekket,
- hvilke deler som ikke kan vurderes ut fra materialet,
- hvilke antakelser du gjør,
- hvilke begrensninger analysen har,
- hvilke rammeverk og versjoner du legger til grunn,
- hvordan du skiller mellom sikker, sannsynlig og usikker funksjonalitet.

Bruk følgende evidensgradering:

- Høy evidens: direkte støttet av kildekode, tester, API-kontrakter, datamodeller eller eksplisitt dokumentasjon.
- Middels evidens: støttet av navngivning, struktur, kontrollflyt eller flere indirekte tegn.
- Lav evidens: plausibel tolkning, men ikke tilstrekkelig dokumentert.
- Ikke verifisert: kan ikke bekreftes ut fra tilgjengelig materiale.

2. Kodeorientert funksjonskartlegging

Analyser kildekoden for å identifisere:

- inngangspunkter, for eksempel UI-komponenter, controllere, API-endepunkter, meldingskonsumenter, CLI-kommandoer eller batch-jobber,
- sentrale domeneobjekter, entiteter, verdityper og aggregater,
- brukerroller, systemroller, eksterne aktører og integrasjoner,
- kommandoer, spørringer, hendelser og tilstandsoverganger,
- valideringsregler, autorisasjonsregler og forretningsregler,
- persistens, datalagring, databaser, skjemaer og migreringer,
- feilhåndtering, avvik, unntak og alternative flyter,
- sikkerhet, tilgangsstyring, logging, revisjon og sporbarhet,
- tester som bekrefter forventet atferd,
- konfigurasjon som påvirker systemets funksjonelle oppførsel.

For hvert viktig funn skal du oppgi sporbarhet til relevante filer, klasser, funksjoner, moduler, tester, endepunkter eller konfigurasjoner dersom denne informasjonen finnes.

3. UFO / ontologisk analyse

Bruk UFO som støtte for å forstå domenet og den realiserte systematferden.

UFO-A:
Identifiser sentrale objekter, typer, roller, relatorer, egenskaper, tilstander og relasjoner.

UFO-B:
Identifiser hendelser, prosesser, aktiviteter, tilstandsendringer, livssykluser og tidslige forløp.

UFO-C:
Identifiser aktører, intensjoner, sosiale relasjoner, forpliktelser, rettigheter, ansvar og normative regler som kommer til uttrykk i koden.

UFO-S:
Brukes bare dersom løsningen realiserer tjenester, tjenestekontrakter, tjenesteytere, tjenestemottakere eller tjenesteopplevelser.

UFO-L:
Brukes bare dersom koden uttrykker juridiske rettigheter, plikter, samtykker, fullmakter, kontrakter, regulatoriske krav eller compliance-regler.

Resultatet fra UFO-analysen skal brukes til å forbedre presisjonen i brukerhistorier, aktører, begreper, forretningsregler og Gherkin-scenarier.

4. iStar 2.0 / mål- og aktøranalyse

Identifiser, der det er mulig ut fra koden:

- aktører,
- mål,
- softgoals,
- oppgaver,
- ressurser,
- avhengigheter,
- avhengighetsrisikoer,
- målkonflikter,
- alternative strategier.

Knytt analysen til realisert funksjonalitet. Ikke anta organisatoriske mål som ikke kan støttes av materialet.

Bruk iStar-analysen til å formulere brukerhistorier i dette formatet:

Som [aktør eller rolle]
ønsker jeg [mål eller evne]
slik at [forretningsverdi, brukerbehov eller systemnytte].

5. TOGAF ADM / arkitekturstruktur

Bruk relevante deler av TOGAF ADM til å strukturere funnene på arkitekturnivå. Ikke bruk alle faser ukritisk.

Vurder bare faser som er nyttige for å forstå realisert funksjonalitet:

- Scope og krav
- Architecture Vision
- Baseline Architecture
- Target Architecture, dersom det finnes tegn til ønsket eller planlagt utvikling
- Gap Analysis
- Opportunities and Solutions
- Migration Planning
- Implementation Governance
- Architecture Change Management

For hver relevant fase skal du angi:

- hva koden viser,
- hva som er uklart,
- hvilke brukerhistorier eller Gherkin-scenarier funnet påvirker.

Faser som ikke er relevante skal merkes som “ikke anvendelig” med kort begrunnelse.

6. ArchiMate / arkitekturmodellering

Beskriv funnene tekstlig etter relevante ArchiMate-lag. Bruk bare lag som faktisk gir innsikt i materialet:

- Motivation: drivere, mål, krav, begrensninger og prinsipper.
- Strategy: kapabiliteter, verdistrømmer og ressurser.
- Business: aktører, roller, prosesser, tjenester, objekter og regler.
- Application: applikasjonskomponenter, tjenester, API-er, dataobjekter og integrasjoner.
- Technology: infrastruktur, runtime, meldingsplattformer, databaser, nettverk og teknologitjenester.
- Physical: fysiske elementer, dersom relevant.
- Implementation & Migration: leveranser, arbeidspakker, migreringer eller utrullingsstrukturer.

For hvert relevant lag skal du oppgi:

- identifiserte elementer,
- relasjoner mellom elementer,
- hvilke realiserte brukerhistorier elementene støtter,
- mangler eller usikkerheter.

7. Toulmin / argumentasjonsanalyse

For de viktigste tolkningene, anbefalingene og brukerhistoriene skal du vurdere argumentasjonen med Toulmin-modellen:

- Claim: hva påstås å være realisert?
- Grounds: hvilke kodefunn, tester eller artefakter støtter påstanden?
- Warrant: hvorfor viser disse funnene at funksjonaliteten faktisk er realisert?
- Backing: hvilken ekstra støtte finnes, for eksempel dokumentasjon, tester eller konsistent arkitektur?
- Qualifier: hvor sikker er konklusjonen?
- Rebuttal: hva kan svekke eller motbevise tolkningen?

Bruk Toulmin-analysen til å unngå overtolkning.

8. Utledning av realiserte brukerhistorier

Basert på analysen skal du lage en katalog over realiserte brukerhistorier.

Hver brukerhistorie skal ha:

- unik ID,
- tittel,
- aktør eller rolle,
- brukerhistorie i formatet “Som / ønsker jeg / slik at”,
- kort beskrivelse,
- forretningsverdi eller systemnytte,
- evidensgrad,
- sporbarhet til kode, tester, API, database, konfigurasjon eller dokumentasjon,
- avhengigheter,
- relevante forretningsregler,
- relevante unntak og alternative flyter,
- status: realisert, delvis realisert, implisitt eller ikke verifisert.

Ikke slå sammen ulike brukerintensjoner i én stor historie dersom de bør testes separat.

9. Gherkin-spesifikasjon

For hver realisert eller delvis realisert brukerhistorie skal du lage detaljerte Gherkin-scenarier.

Bruk gyldig og tydelig Gherkin-struktur:

Feature:
  Kort beskrivelse av funksjonaliteten og dens verdi.

Background:
  Felles forutsetninger som gjelder for flere scenarier.

Rule:
  En forretningsregel eller systemregel som scenariene hører til.

Scenario:
  Konkret eksempel på normalflyt, alternativ flyt eller feilsituasjon.

Scenario Outline:
  Brukes når samme regel bør testes med flere datavariasjoner.

Examples:
  Tabell med representative testdata.

Bruk Given / When / Then / And / But presist:

- Given beskriver starttilstand, data, brukerrolle eller systemkontekst.
- When beskriver handlingen eller hendelsen som utløser oppførselen.
- Then beskriver observerbart resultat.
- And brukes for å legge til flere forhold på samme nivå.
- But brukes for kontrasterende forventninger.

Gherkin-scenariene skal være:

- konkrete nok til å kunne brukes som akseptansekriterier,
- sporbare til realisert kode,
- forståelige for både forretning og utviklere,
- uten implementasjonsdetaljer der det ikke er nødvendig,
- presise nok til å kunne automatiseres som tester,
- eksplisitte om roller, data, rettigheter, valideringer og forventede resultater.

Dekk der det er relevant:

- normalflyt,
- alternative flyter,
- valideringsfeil,
- autorisasjonsfeil,
- manglende data,
- ugyldige data,
- integrasjonsfeil,
- idempotens,
- samtidighet,
- tilstandsoverganger,
- audit/logging,
- sikkerhet,
- grenseverdier,
- datakonsistens,
- feilmeldinger,
- sideeffekter,
- hendelser eller meldinger som publiseres,
- persistens og endret systemtilstand.

10. Sporbarhet

Lag en sporbarhetsmatrise som kobler sammen:

- funn,
- kodeartefakt,
- domeneobjekt,
- aktør,
- mål,
- brukerhistorie,
- Gherkin-scenario,
- evidensgrad,
- usikkerhet eller antakelse.

Sporbarheten skal gjøre det mulig å se hvorfor en brukerhistorie eller et scenario er inkludert.

11. Outputformat

Lever svaret med følgende struktur:

11.1 Kort sammendrag

Oppsummer hva systemet ser ut til å gjøre, hvilke hovedkapabiliteter som er realisert, og hvor sikker analysen er.

11.2 Analysegrunnlag, antakelser og avgrensninger

Angi analysert materiale, manglende informasjon, eksplisitte antakelser, avgrensninger og valgt bruk av rammeverk.

11.3 Kodebasert funksjonskartlegging

Beskriv sentrale inngangspunkter, moduler, dataobjekter, regler, hendelser, tjenester, integrasjoner og tester.

11.4 Analyse per rammeverk

Presenter relevante funn fra:

- UFO
- iStar 2.0
- TOGAF ADM
- ArchiMate
- Toulmin

Ikke bruk lange teoretiske beskrivelser av rammeverkene. Fokuser på hva de avdekker om koden.

11.5 Realiserte brukerhistorier

Presenter brukerhistoriene i tabellform med minst disse kolonnene:

- ID
- Tittel
- Aktør
- Brukerhistorie
- Status
- Evidensgrad
- Sporbarhet
- Viktige regler
- Usikkerheter

11.6 Detaljerte Gherkin-spesifikasjoner

For hver brukerhistorie, lever Gherkin i kodeblokk.

Eksempelstruktur:

```gherkin
Feature: [Kort navn på realisert kapabilitet]
  Som [aktør]
  ønsker jeg [mål]
  slik at [verdi]

  Background:
    Given [felles forutsetning]
    And [eventuell felles testdata eller rolle]

  Rule: [forretningsregel eller systemregel]

    Scenario: [normalflyt]
      Given [starttilstand]
      When [bruker eller system utfører handling]
      Then [forventet observerbart resultat]
      And [eventuell tilstandsendring eller sideeffekt]

    Scenario: [valideringsfeil eller alternativ flyt]
      Given [starttilstand]
      When [ugyldig handling eller data]
      Then [forventet avvisning eller feilmelding]
      And [systemtilstand skal være uendret]

    Scenario Outline: [variasjoner av samme regel]
      Given [starttilstand med <parameter>]
      When [handling utføres]
      Then [forventet <resultat>]

      Examples:
        | parameter | resultat   |
        | verdi 1   | resultat 1 |
        | verdi 2   | resultat 2 |
```

11.7 Sporbarhetsmatrise

Lag en tabell som kobler kodefunn til brukerhistorier og scenarier.

Tabellen bør minst ha disse kolonnene:

- Funn-ID
- Kodeartefakt
- Domeneobjekt
- Aktør
- Mål
- Brukerhistorie-ID
- Gherkin-scenario
- Evidensgrad
- Usikkerhet eller antakelse

11.8 Toulmin-vurdering av hovedargumentene

Vurder de viktigste påstandene om realisert funksjonalitet, med:

- claim,
- grounds,
- warrant,
- backing,
- qualifier,
- rebuttal.

11.9 Prioriterte forbedringsforslag

Gi forbedringsforslag for:

- kode,
- tester,
- domenemodell,
- arkitektur,
- dokumentasjon,
- Gherkin-spesifikasjoner,
- sporbarhet,
- manglende eller usikker funksjonalitet.

Prioriter forslagene etter nytte og risiko.

12. Viktige regler for svaret

Følg disse reglene strengt:

- Ikke oppfinn funksjonalitet.
- Ikke presenter antakelser som fakta.
- Ikke gjør analysen mer sikker enn koden gir grunnlag for.
- Ikke bruk rammeverkene mekanisk.
- Ikke lag generiske brukerhistorier uten sporbarhet.
- Ikke lag Gherkin-scenarier som ikke kan knyttes til realisert eller sannsynlig realisert systematferd.
- Marker eksplisitt når noe bare er en tolkning.
- Bruk norsk språk, men behold Gherkin-nøkkelord på engelsk.
- Bruk konsise, presise og testbare formuleringer.
- Prioriter faktisk systematferd fremfor arkitekturteori.
- Når dokumentasjon og kode motsier hverandre, skal du prioritere kode og tester som evidens for realisert funksjonalitet.
- Når tester motsier produksjonskode, skal du beskrive avviket eksplisitt og ikke late som systematferden er entydig.
- Når funksjonalitet bare finnes i kommentarer, README eller TODO-er, skal den ikke regnes som realisert uten støtte i kode eller tester.
- Når du ikke kan fastslå aktør, mål eller forretningsverdi, skal du markere dette som usikkert i stedet for å gjette.