Захоўвайце прасочвальнасць патрабаванняў пры зменах праграмы

Апісвайце паводзіны, якія хтосьці можа праверыць

«Стварыць сучасны экспарт даных кліентаў» пакідае істотныя рашэнні адкрытымі. Гэта не вызначае карыстальнікаў, запісы, палі або паводзіны пры памылцы. Агент павінен альбо спытаць, альбо зрабіць дапушчэнні. Незапісаныя дапушчэнні цяжка праверыць пазней.

Выкарыстоўвайце выдуманае патрабаванне з выразнай мяжой: аўтэнтыфікаваны кіраўнік можа экспартаваць даныя актыўных кліентаў сваёй арганізацыі. Экспарт змяшчае ID кліента і адлюстраванае імя. Ён выключае кантактныя звесткі і архіўныя запісы. Карыстальнік без ролі кіраўніка не атрымлівае экспарт.

Усё яшчэ патрэбныя рашэнні пра фармат, аб’ём, час адказу і апрацоўку памылак. Яўна пазначайце невядомае. Карысная спецыфікацыя паказвае нявызначанасць замест таго, каб хаваць яе ва ўпэўненым тэксце.

Аддзяляйце патрабаванні ад выбару рэалізацыі

Карыстальніку патрэбны дазволены набор запісаў у прыдатным фармаце. Запыт да базы даных, бібліятэка і структура endpoint — выбары рэалізацыі. Звязвайце іх з патрабаваннем, не лічачы кожны бягучы выбар пастаяннай бізнес-патрэбай.

Запісвайце рашэнне з істотнымі наступствамі разам з кантэкстам, альтэрнатывамі і прычынай. Напрыклад, сінхронны экспарт можа падыходзіць для малых аб’ёмаў. Большы аб’ём можа патрабаваць фонавай задачы і асобнай праверкі аўтарызацыі спампоўвання.

Па магчымасці захоўвайце патрабаванне нязменным, ствараючы версіі змененага рашэння. Гэта дапамагае рэцэнзентам адрозніваць іншую рэалізацыю ад іншага абяцання карыстальнікам.

Стварыце кароткі ланцуг доказаў

Выкарыстоўвайце ідэнтыфікатары, якія застаюцца зразумелымі пры праверцы. У гэтым прыкладзе EXPORT-01 можа вызначаць мяжу арганізацыі. Назва ілюстрацыйная, гэта не абавязковая сістэма нумарацыі.

Ланцуг павінен паказваць на рэальныя доказы. Назва тэсту з ID патрабавання не даказвае, што праверачнае сцверджанне яго правярае. Вывучыце тэст і шлях кода production, які ён выпрабоўвае.

SSDF ад NIST дае кантэкст для патрабаванняў і праверкі ў бяспечнай распрацоўцы. Выкарыстоўвайце прасочвальнасць, каб зрабіць гэтыя дзеянні прыдатнымі для вывучэння, а не ствараць дакументацыю дзеля яе самой. Прачытайце framework.

Пераглядайце ўплыў змененага дапушчэння

Дапусцім, бізнесу цяпер патрэбныя даныя архіўных кліентаў. Гэтая змена закранае больш, чым сцяг запыту. Праверце правілы захоўвання, аўтарызацыю, чаканы аб’ём, тлумачэнні карыстальнікам і значэнне наяўных справаздач.

Пазначце закранутыя дакументы і праверкі для перагляду. Захавайце папярэдняе рашэнне, каб спецыяліст па эксплуатацыі мог растлумачыць стары выпуск. Не перапісвайце моўчкі гісторыю, каб найноўшы праект выглядаў непазбежным.

Агент можа дапамагчы знайсці спасылкі і прапанаваць абнаўленні. Адказныя павінны вырашыць супярэчлівыя патрабаванні і прыняць змененыя паводзіны. Спіс адпаведных файлаў — адпраўны пункт, а не поўная ацэнка ўплыву.

Захоўвайце запіс дастаткова малым для выкарыстання

Запісвайце рашэнні, якія ўплываюць на рэалізацыю, праверку і эксплуатацыю. Не паўтарайце адно патрабаванне ў многіх не звязаных паміж сабой дакументах. Аддавайце перавагу спасылкам на адну крыніцу, якую падтрымліваюць актуальнай.

Перад прыняццем змены спытайце, ці можа рэцэнзент прасачыць яе мэту да фактычных доказаў. Перад эксплуатацыяй спытайце, ці можа адказны за сэрвіс знайсці адпаведную мяжу і рашэнне аб аднаўленні. Гэта практычныя праверкі карыснай прасочвальнасці.