Зачувајте ја следливоста на барањата додека софтверот се менува

Опишете однесување што некој може да го провери

„Создајте современ извоз на податоци за клиенти“ остава важни одлуки отворени. Не ги одредува корисниците, записите, полињата или однесувањето при неуспех. Агент мора или да праша или да претпостави. Незапишаните претпоставки тешко се прегледуваат подоцна.

Користете измислено барање со јасна граница: раководител со потврден идентитет може да извезува податоци за активни клиенти од својата организација. Извозот ги содржи ID на клиентот и името за приказ. Ги исклучува податоците за контакт и архивираните записи. Корисник без раководителска улога не добива извоз.

Сè уште се потребни одлуки за форматот, обемот, времето за одговор и постапувањето при неуспех. Јасно означете го непознатото. Корисна спецификација ја покажува неизвесноста наместо да ја крие во уверлив текст.

Одделете ги барањата од изборите за имплементација

На корисникот му треба дозволен сет записи во употреблив формат. Барањето до базата, библиотеката и структурата на крајната точка се избори за имплементација. Поврзете ги со барањето без да го третирате секој тековен избор како трајна деловна потреба.

Запишете одлука со значителни последици заедно со нејзиниот контекст, алтернативите и причината. На пример, синхрон извоз може да одговара за мал обем. Поголем обем може да бара задача во заднина и одделна проверка за авторизација при преземање.

Зачувајте го барањето стабилно каде што е можно, а верзионирајте ја изменетата одлука. Ова им помага на рецензентите да разликуваат поинаква имплементација од поинакво ветување кон корисниците.

Создајте краток синџир на докази

Користете идентификатори што остануваат разбирливи при преглед. Во овој пример, EXPORT-01 може да ја идентификува границата на организацијата. Името е илустративно, а не задолжителен систем за нумерирање.

Синџирот мора да води до вистински докази. Име на тест што го содржи ID на барањето не докажува дека проверуваниот услов го проверува тоа барање. Испитајте ги тестот и патеката низ продукцискиот код што ја извршува.

SSDF на NIST дава контекст за барањата и проверките во безбедниот развој. Користете следливост за овие активности да може да се испитаат, наместо да создавате документација само заради документација. Прочитајте ја рамката.

Прегледајте го влијанието на изменета претпоставка

Да претпоставиме дека бизнисот сега бара и податоци за архивирани клиенти. Последиците од оваа промена не се ограничуваат на знаменце во барањето до базата. Проверете ги правилата за чување, авторизацијата, очекуваниот обем, објаснувањата за корисниците и значењето на постојните извештаи.

Означете ги засегнатите документи и проверки за преглед. Зачувајте ја претходната одлука за оператор да може да објасни постаро издание. Не препишувајте ја молкум историјата за најновиот дизајн да изгледа неизбежен.

Агент може да помогне да се најдат референци и да предложи ажурирања. Одговорните лица мора да ги разрешат противречните барања и да го прифатат изменетото однесување. Список на датотеки што се совпаѓаат е почетна точка, а не целосна оцена на влијанието.

Одржувајте го записот доволно мал за употреба

Запишете ги одлуките што влијаат врз имплементацијата, проверката и работењето. Не повторувајте го истото барање во многу неповрзани документи. Претпочитајте врски до еден одржуван извор.

Пред да прифатите промена, прашајте дали рецензент може да ја следи нејзината цел до вистинските докази. Пред да ја ставите во употреба, прашајте дали одговорниот за услугата може да ги најде релевантната граница и одлуката за обновување. Ова се практични проверки за корисна следливост.