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

Taiga Learning · Працоўны ліст
https://taiga.training/be/lessons/specifications/

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

## Мэты навучання
- Пісаць правяральнае патрабаванне з выразнымі межамі.
- Прасочваць патрабаванне праз змену і яе праверкі.
- Выяўляць залежныя дакументы, на якія ўплывае змена дапушчэння.

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

## Ваш адказ
- Сцэнарый і абсяг:
- Дапушчэнні і адкрытыя пытанні:
- Прапанаваны адказ або рашэнне з абгрунтаваннем:

## Праверце свой адказ
| Сцверджанне або крытэрый | Доказ або тэст | Вынік або прабел | Адказны |
| --- | --- | --- | --- |
| | | | |
| | | | |
| | | | |

## Наступнае дзеянне
- Дзеянне, адказны і дата:
- Калі вы перагледзіце гэты адказ?

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

## Крыніцы
- [NIST: Secure Software Development Framework](https://csrc.nist.gov/pubs/sp/800/218/final)
- [Google Engineering Practices: What to look for in a code review](https://google.github.io/eng-practices/review/reviewer/looking-for.html)

Гэты працоўны ліст падтрымлівае навучанне. Само яго запаўненне не дазваляе змены ў production-асяроддзі.