# Hold krav sporbare når programvaren endres

Taiga Learning · Arbeidsark
https://taiga.training/nb/lessons/specifications/

Bruk fiktiv eller godkjent informasjon. Ikke legg hemmeligheter i dette arbeidsarket.

## Læringsmål
- Skriv et observerbart krav med tydelige grenser.
- Spor et krav gjennom en endring og dens kontroller.
- Identifiser etterfølgende dokumenter som påvirkes av en endret antakelse.

## Øvelse
Skriv et krav om at en leder skal kunne eksportere aktive kunder. Ta med tillatte brukere, organisasjonsgrense, felt, feilatferd og en målbar betingelse for fullføring. Knytt det til en fiktiv test og utgivelse. Endre deretter kravet til å inkludere arkiverte kunder, og list opp berørte beslutninger.

## Ditt svar
- Scenario og omfang:
- Antakelser og åpne spørsmål:
- Foreslått svar eller beslutning, med begrunnelser:

## Verifiser svaret ditt
| Påstand eller kriterium | Bevis eller test | Resultat eller gap | Eier |
| --- | --- | --- | --- |
| | | | |
| | | | |
| | | | |

## Neste handling
- Handling, eier og dato:
- Når vil du gjennomgå dette svaret?

## Prinsipp å beholde
En spesifikasjon er nyttig når påstandene henger sammen med beslutninger og verifiserbar atferd. Hold forbindelsene oppdaterte når systemet endres.

## Kilder
- [NIST: Secure Software Development Framework](https://csrc.nist.gov/pubs/sp/800/218/final)
- [Google Engineering Practices: What to look for in a code review](https://google.github.io/eng-practices/review/reviewer/looking-for.html)

Dette arbeidsarket støtter læring. Fullføring gir ikke i seg selv tillatelse til en produksjonsendring.