# Сохраняйте прослеживаемость требований при изменении ПО

Taiga Learning · Рабочий лист
https://taiga.training/ru/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.