Mbajini kërkesat të gjurmueshme ndërsa softueri ndryshon

Përshkruani sjellje që dikush mund ta verifikojë

«Krijoni një eksport modern të të dhënave të klientëve» lë të hapura vendime të rëndësishme. Nuk përcakton përdoruesit, regjistrimet, fushat ose sjelljen në rast dështimi. Agjenti duhet ose të pyesë, ose të bëjë supozime. Supozimet e paregjistruara janë të vështira për t’u shqyrtuar më vonë.

Përdorni një kërkesë imagjinare me kufi të qartë: një menaxher i autentikuar mund të eksportojë të dhënat e klientëve aktivë të organizatës së vet. Eksporti përmban ID-në e klientit dhe emrin e shfaqur. Ai përjashton të dhënat e kontaktit dhe regjistrimet e arkivuara. Një përdorues pa rolin e menaxherit nuk merr eksport.

Kjo ende kërkon vendime për formatin, vëllimin, kohën e përgjigjes dhe trajtimin e dështimeve. Shënoni qartë të panjohurat. Një specifikim i dobishëm e nxjerr në pah pasigurinë, në vend që ta fshehë pas një formulimi të shprehur me bindje.

Ndani kërkesat nga zgjedhjet e zbatimit

Përdoruesit i nevojitet një grup i lejuar regjistrimesh në një format të përdorshëm. Query i bazës së të dhënave, biblioteka dhe struktura e endpoint-it janë zgjedhje zbatimi. Lidhini me kërkesën pa e trajtuar çdo zgjedhje aktuale si nevojë të përhershme biznesi.

Regjistroni një vendim me pasoja të rëndësishme bashkë me kontekstin, alternativat dhe arsyen e tij. Për shembull, eksporti sinkron mund të përshtatet për vëllime të vogla. Një vëllim më i madh mund të kërkojë një punë në sfond dhe një kontroll të veçantë autorizimi për shkarkimin.

Mbajeni kërkesën të qëndrueshme kur është e mundur, ndërsa versiononi vendimin e ndryshuar. Kjo i ndihmon shqyrtuesit të dallojnë një zbatim të ndryshëm nga një premtim i ndryshëm ndaj përdoruesve.

Krijoni një zinxhir të shkurtër evidence

Përdorni identifikues që mbeten të kuptueshëm gjatë shqyrtimeve. Në këtë shembull, EXPORT-01 mund të identifikojë kufirin e organizatës. Emri është ilustrues, jo sistem i detyrueshëm numërimi.

Zinxhiri duhet të tregojë evidencë reale. Një emër testi që përmban ID-në e kërkesës nuk provon se pohimi i testit e kontrollon atë kërkesë. Shqyrtoni testin dhe rrugën e kodit të prodhimit që ai ekzekuton.

SSDF i NIST jep kontekst për kërkesat dhe verifikimin brenda zhvillimit të sigurt. Përdoreni gjurmueshmërinë për t’i bërë këto veprimtari të shqyrtueshme, jo për të prodhuar dokumentacion si qëllim më vete. Lexoni kuadrin.

Shqyrtoni ndikimin e një supozimi të ndryshuar

Supozoni se biznesit tani i duhen të dhënat e klientëve të arkivuar. Ky ndryshim prek më shumë se një parametër query. Kontrolloni rregullat e ruajtjes, autorizimin, vëllimin e pritshëm, shpjegimet për përdoruesit dhe kuptimin e raporteve ekzistuese.

Shënoni dokumentet dhe kontrollet e prekura për shqyrtim. Ruajeni vendimin e mëparshëm që një operator të mund të shpjegojë një version më të vjetër. Mos e rishkruani historinë në heshtje për ta paraqitur projektimin e fundit si të pashmangshëm.

Një agjent mund të ndihmojë të gjejë referenca dhe të propozojë përditësime. Personat përgjegjës duhet të zgjidhin kërkesat kundërshtuese dhe të pranojnë sjelljen e ndryshuar. Një listë skedarësh që përputhen është pikënisje, jo vlerësim i plotë i ndikimit.

Mbajeni regjistrin mjaft të shkurtër për t’u përdorur

Regjistroni vendimet që ndikojnë në zbatim, verifikim dhe funksionim. Shmangni përsëritjen e së njëjtës kërkesë në shumë dokumente të palidhura. Preferoni lidhje drejt një burimi të vetëm që mirëmbahet.

Para se të pranoni një ndryshim, pyesni nëse një shqyrtues mund ta ndjekë qëllimin e tij deri te evidenca reale. Para se ta vini në funksionim, pyesni nëse personi përgjegjës për shërbimin mund të gjejë kufirin përkatës dhe vendimin e rikuperimit. Këto janë teste praktike të gjurmueshmërisë së dobishme.