Bevar sporbarheden i krav, når software ændres

Beskriv adfærd, som nogen kan kontrollere

»Lav en moderne kundeeksport« efterlader vigtige beslutninger åbne. Det definerer ikke brugere, poster, felter eller fejladfærd. En agent må enten spørge eller gøre antagelser. Uregistrerede antagelser er svære at gennemgå senere.

Brug et fiktivt krav med en klar grænse: En autentificeret leder kan eksportere aktive kunder fra sin egen organisation. Eksporten indeholder kunde-ID og vist navn. Den udelader kontaktoplysninger og arkiverede poster. En bruger uden lederrollen modtager ingen eksport.

Der skal stadig træffes beslutninger om format, mængde, svartid og fejlhåndtering. Markér ukendte forhold udtrykkeligt. En brugbar specifikation viser usikkerhed i stedet for at skjule den i sikker formulering.

Skeln mellem krav og implementeringsvalg

Brugeren har brug for et tilladt sæt poster i et brugbart format. Databaseforespørgsel, bibliotek og endpointstruktur er implementeringsvalg. Knyt dem til kravet uden at behandle hvert nuværende valg som et permanent forretningsbehov.

Registrér en vigtig beslutning med dens kontekst, alternativer og begrundelse. Synkron eksport kan for eksempel passe til små datamængder. Større mængder kan kræve et baggrundsjob og en særskilt rettighedskontrol ved download.

Bevar kravet, hvor det er muligt, mens du versionsstyrer den ændrede beslutning. Det hjælper reviewere med at skelne en anden implementering fra et andet løfte til brugerne.

Lav en kort dokumentationskæde

Brug identifikatorer, der er forståelige under review. I dette eksempel kan EXPORT-01 identificere organisationsgrænsen. Navnet er et eksempel, ikke et påkrævet nummereringssystem.

Kæden skal pege på virkelig dokumentation. Et testnavn med kravets ID beviser ikke, at assertionen kontrollerer kravet. Undersøg testen og det produktionsforløb, den afprøver.

NIST’s SSDF giver kontekst for krav og verifikation i sikker udvikling. Brug sporbarhed til at gøre aktiviteterne gennemskuelige frem for at producere dokumentation for dens egen skyld. Læs rammeværket.

Gennemgå virkningen af en ændret antagelse

Antag, at virksomheden nu har brug for arkiverede kunder. Ændringen påvirker mere end et flag i en forespørgsel. Kontrollér opbevaringsregler, rettigheder, forventet datamængde, forklaringer til brugeren og betydningen af eksisterende rapporter.

Markér berørte dokumenter og kontroller til review. Bevar den tidligere beslutning, så en driftsansvarlig kan forklare en ældre release. Omskriv ikke stiltiende historikken, så det nyeste design fremstår som det eneste mulige.

En agent kan hjælpe med at finde henvisninger og foreslå opdateringer. De ansvarlige skal afklare modstridende krav og acceptere den ændrede adfærd. En liste over matchende filer er et udgangspunkt, ikke en komplet konsekvensanalyse.

Hold dokumentationen lille nok til at blive brugt

Registrér de beslutninger, der påvirker implementering, verifikation og drift. Undgå at gentage det samme krav i mange adskilte dokumenter. Foretræk links til én vedligeholdt kilde.

Spørg før accept af en ændring, om en reviewer kan følge dens formål frem til den faktiske dokumentation. Spørg før drift, om tjenesteejeren kan finde den relevante grænse og beslutning om gendannelse. Det er praktiske mål for nyttig sporbarhed.