# Bevar sporbarheden i krav, når software ændres

Taiga Learning · Arbejdsark
https://taiga.training/da/lessons/specifications/

Brug fiktive eller godkendte oplysninger. Skriv ikke secrets i arbejdsarket.

## Læringsmål
- Skriv et observerbart krav med udtrykkelige grænser.
- Spor et krav gennem en ændring og dens kontroller.
- Find efterfølgende dokumenter, der påvirkes af en ændret antagelse.

## Øvelse
Skriv et krav om, at en leder kan eksportere aktive kunder. Medtag tilladte brugere, organisationsgrænse, felter, fejladfærd og en målbar betingelse for færdiggørelse. Link det til en fiktiv test og release. Udvid derefter kravet til arkiverede kunder, og angiv de berørte beslutninger.

## Dit svar
- Scenarie og omfang:
- Antagelser og åbne spørgsmål:
- Foreslået svar eller beslutning med begrundelser:

## Verificér dit svar
| Påstand eller kriterium | Dokumentation eller test | Resultat eller mangel | Ansvarlig |
| --- | --- | --- | --- |
| | | | |
| | | | |
| | | | |

## Næste handling
- Handling, ansvarlig og dato:
- Hvornår vil du gennemgå dette svar?

## Princip at huske
En specifikation er nyttig, når dens påstande hænger sammen med beslutninger og verificerbar adfærd. Hold forbindelserne aktuelle, når systemet ændres.

## 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)

Arbejdsarket understøtter læring. Gennemførelse autoriserer ikke i sig selv en produktionsændring.