Hold krav sporbare når programvaren endres

Beskriv atferd noen kan verifisere

«Lag en moderne kundeeksport» lar viktige beslutninger stå åpne. Det definerer ikke brukere, poster, felt eller feilatferd. En agent må enten spørre eller gjøre antakelser. Uregistrerte antakelser er vanskelige å gjennomgå senere.

Bruk et fiktivt krav med en klar grense: En autentisert leder kan eksportere aktive kunder fra sin egen organisasjon. Eksporten inneholder kunde-ID og visningsnavn. Den utelater kontaktopplysninger og arkiverte poster. En bruker uten lederrollen får ingen eksport.

Dette krever fortsatt beslutninger om format, volum, responstid og feilhåndtering. Marker ukjente forhold tydelig. En nyttig spesifikasjon avdekker usikkerhet fremfor å skjule den i selvsikker tekst.

Skill krav fra implementeringsvalg

Brukeren trenger et tillatt sett poster i et brukbart format. Databasespørring, bibliotek og endpointstruktur er implementeringsvalg. Knytt dem til kravet uten å behandle hvert gjeldende valg som et permanent forretningsbehov.

Registrer en vesentlig beslutning med kontekst, alternativer og begrunnelse. Synkron eksport kan for eksempel passe små volumer. Et større volum kan kreve en bakgrunnsjobb og en separat autorisasjonskontroll for nedlasting.

Hold kravet stabilt der det er mulig, og versjoner den endrede beslutningen. Det hjelper reviewere med å skille en annen implementering fra et annet løfte til brukerne.

Lag en kort dokumentasjonskjede

Bruk identifikatorer som er forståelige i review. I eksemplet kan EXPORT-01 identifisere organisasjonsgrensen. Navnet er illustrativt, ikke et påkrevd nummereringssystem.

Kjeden må peke til reell dokumentasjon. Et testnavn med krav-ID beviser ikke at testpåstanden kontrollerer kravet. Undersøk testen og produksjonsveien den tester.

NISTs SSDF gir kontekst for krav og verifisering i sikker utvikling. Bruk sporbarhet til å gjøre aktivitetene etterprøvbare fremfor å produsere dokumentasjon for dokumentasjonens skyld. Les rammeverket.

Gjennomgå virkningen av en endret antakelse

Anta at virksomheten nå trenger arkiverte kunder. Endringen påvirker mer enn et spørringsflagg. Kontroller oppbevaringsregler, autorisasjon, forventet volum, brukerforklaringer og betydningen av eksisterende rapporter.

Marker berørte dokumenter og kontroller for gjennomgang. Bevar den tidligere beslutningen slik at en driftsansvarlig kan forklare en eldre utgivelse. Ikke skriv om historien ubemerket for å få det nyeste designet til å virke uunngåelig.

En agent kan finne referanser og foreslå oppdateringer. De ansvarlige må avklare motstridende krav og akseptere endret atferd. En liste over treff i filer er et utgangspunkt, ikke en fullstendig konsekvensanalyse.

Hold registreringen liten nok til å brukes

Registrer beslutningene som påvirker implementering, verifisering og drift. Unngå å gjenta samme krav i mange atskilte dokumenter. Foretrekk lenker til én vedlikeholdt kilde.

Spør før en endring aksepteres, om en reviewer kan følge formålet til den faktiske dokumentasjonen. Spør før drift om tjenesteeieren kan finne relevant grense og gjenopprettingsbeslutning. Det er praktiske tester på nyttig sporbarhet.