Атомарность (или "единичность")

Каждое требование должно быть самодостаточным и описывать только одну ситуацию. Если требование можно разбить на несколько независимых, оно перестаёт быть атомарным. Проблемы с атомарностью возникают, когда в одном требовании описываются разные элементы интерфейса или разные состояния/эффекты от действий пользователя, что затрудняет его понимание и приводит к путанице.

Пример 1: "Если пользователь нажимает 'Отмена', он должен вернуться на главную страницу, а изменения должны быть сброшены."
Здесь объединены два разных сценария: возврат на главную страницу и сброс изменений, которые могут быть реализованы независимо друг от друга.
Атомарные требования: 
- при нажатии 'Отмена', все внесенные изменения должны быть сброшены.
- при нажатии 'Отмена', пользователь должен вернуться на главную страницу.

Пример 2: "На странице отчёта должно отображаться имя пользователя, а также должна быть возможность скачивания PDF-версии отчёта."
Это требование описывает два разных элемента интерфейса и две разные функции программы: отображение имени пользователя и возможность скачать отчет.
Атомарные требования: 
- "На странице отчёта должно отображаться имя пользователя."
- "На странице отчёта должна быть кнопка для скачивания PDF-версии отчёта."

Необходимость (или "обязательность")

Каждое требование должно приносить реальную пользу бизнесу, выделять продукт на рынке или обеспечивать соблюдение стандартов и правил. Если какое-то требование устарело, было замещено другим или просто не обязательно для реализации, его необходимо удалить из набора требований.

Пример 1: "В приложении должна быть возможность авторизоваться через социальную сеть Line."
Если продукт ориентирован на российскую аудиторию, доля пользователей из стран Азии составляет мизерный процент, и компания НЕ планирует продвижение в Азии, то поддержка авторизации через соц. сеть, популярную именно в Азии, не добавляет существенной ценности и не соответствует целям компании. Такое требование не является необходимым и обязательным для реализации.

Пример 2: 
Первоначальное требование: "Пользователи должны иметь возможность вернуться на предыдущую страницу с помощью кнопки «Назад»."
Новое требование: "Пользователи должны иметь возможность вернуться на предыдущую страницу с помощью жеста свайпа."
Кнопка «Назад» становится ненужной после внедрения жеста. Так как жест выполняет ту же функцию, но удобнее и соответствует современным стандартам пользовательского интерфейса. После удаления кнопки "Назад" должно быть удалено и требование о ней. Иначе будет путаница.

Пример 3: "Приложение должно поддерживать браузер Internet Explorer 10." Это требование стало устаревшим и должно быть удалено, так как Internet Explorer 10 больше не используется и не поддерживается разработчиками.

Прослеживаемость (или "трассируемость")

Требования должны быть оформлены в структурированном виде и, в идеале, иметь уникальные идентификаторы. В контексте тестирования прослеживаемые (или "трассируемые") требования — это те, которые удобно связать с тестами. Для этого используются матрицы трассировки. В общем виде такая матрица выглядит так:

В заголовках столбцов таблицы обычно находятся тесты, а в заголовках строк — требования. На пересечении требований и тестов проставляются отметки, означающие, что требование текущей строки покрыто тестовым сценарием текущего столбца. Непрослеживаемые требования очень сложно связать с тестами в таком виде.

Пример 1: 
"Приложение должно обеспечивать высокую безопасность, поддерживать различные уровни доступа для пользователей и администраторов, иметь возможность интеграции с внешними системами, такими как системы управления проектами; также оно должно работать на мобильных устройствах и поддерживать уведомления. Пользовательский интерфейс должен быть интуитивно понятным, с возможностью настройки тем, а производительность должна быть достаточной для работы с большими объемами данных. Важно обеспечить стабильную работу системы при одновременном подключении большого количества пользователей."

У такого полотна требований отсутствует прослеживаемость, потому что:
- нет структуры, выделяющей функциональные и нефункциональные требования;
- отсутствует нумерация требований;
- несколько требований смешаны в одном абзаце, что затрудняет отслеживание и реализацию;
- нет четкого разделения по категориям (безопасность, интерфейс, производительность и т.д.).

Модифицируемость

Модифицируемость требований подразумевает легкость их изменения. Если требования к продукту разбросаны по разным хранилищам или одно и то же требование встречается в нескольких местах, это значительно усложняет их изменение. Хранение требований в единой базе и использование уникальных идентификаторов помогают избежать избыточности и облегчить управление изменениями.

Пример 1: 
В разделе "Авторизация" в Notion: "Все пользователи системы должны проходить двухфакторную аутентификацию для доступа к личным данным."
В разделе "Безопасность" в Confluence: "Все пользователи системы должны проходить двухфакторную аутентификацию для доступа к личным данным."

Одно и то же требование описано как в разделе безопасности, так и в разделе авторизации, ещё и в двух разных хранилищах. При изменении требования в одном месте (например, добавлении новых условий аутентификации) возникает большой риск появления противоречий с другими частями требований. Чтобы внести изменения, придётся прочесывать все хранилища и перечитывать требования, а затем изменять их в нескольких местах. Это увеличивает трудозатраты и время на внесение изменений.

Понятность

Понятность определяется тем, насколько легко требования понимает целевая аудитория. Требования должны быть написаны с использованием терминологии, знакомой всем членам команды, которая их использует в работе. Это позволит избежать недоразумений и неправильной интерпретации. Если требования описаны неясно или с использованием специального жаргона, который не является общепринятым, это усложняет их понимание, выполнение и замедляет онбординг новых сотрудников.

Пример 1:  "Реализовать функцию для повышения скорости отклика с использованием методик принудительного управления."
"Методики принудительного управления" — это термин, который не имеет чёткого определения в контексте IT и не используется для описания подходов к оптимизации времени отклика. Сложно понять, как реализовать такое требование и какие технологии имелись в виду.
Понятное требование: "Реализовать кэширование данных для повышения скорости отклика."

Пример 2:  "Сайт должен быть способен к улучшению взаимодействия через динамическое управление параметрами."
Фразы "улучшение взаимодействия" и "динамическое управление параметрами" слишком абстрактны и не конкретизируют, какие аспекты взаимодействия нужно улучшить и какие параметры должны быть динамически управляемыми. Требование не несёт полезной информации.
Понятное требование: "Сайт должен предоставлять возможность настройки пользовательского интерфейса в реальном времени: переключение светлой и тёмной темы, три варианта величины шрифта, переключение в режим высокой контрастности."