ПОЛНОТА (или "завершенность").
Каждое требование должно содержать всю информацию, необходимую для его понимания, не оставлять пробелов или недомолвок. Этот критерий относится и к бизнес- и к техническим требованиям.

Пример 1: "Пользователь может загрузить данные в формате PDF, CSV и т.д." Неясно, какие ещё форматы поддерживаются помимо указанных. Что подразумевается под «и т.д.»?
Полное требование: "Пользователь может загрузить данные в форматах PDF, CSV и JSON."

Пример 2: "Приложение должно работать на всех популярных мобильных платформах." Неясно, какие платформы считаются «популярными».
Полное требование: "Приложение должно поддерживаться на платформах Android версии 10.0 и выше, iOS версии 13.0 и выше."

Пример 3: "Система должна обрабатывать запросы с высокой производительностью." Не указано, что конкретно подразумевается под «высокой производительностью» (какие показатели важны).
Полное требование: "Система должна обрабатывать до 1000 запросов в секунду с задержкой не более 200 миллисекунд."

НЕПРОТИВОРЕЧИВОСТЬ (или "согласованность").
Требования не должны противоречить друг другу. Обнаружение несоответствий может быть крайне затруднительным, если требования к одной и той же функциональности продукта находятся в разных местах.

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

Пример 2:
- "Отчет должен генерироваться и отправляться пользователю мгновенно."
- "Генерация отчета может занимать до 30 минут в зависимости от объема данных."
Первое требование обещает мгновенную обработку, тогда как второе указывает на значительную задержку, создавая неопределенность в ожиданиях.
Непротиворечивые требования: "Отчет должен генерироваться мгновенно при объеме данных до 200 килобайт и отправляться в течение 30 минут при большем объеме."

КОРРЕКТНОСТЬ
Под корректностью понимается точное соответствие запросам пользователей и бизнеса. Это означает, что требования должны полностью удовлетворять нужды заинтересованных сторон, которые будут использовать эти требования для достижения конкретных целей.

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

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

НЕДВУСМЫСЛЕННОСТЬ (или "однозначность")
Русский язык, как и любой другой, может содержать двусмысленности, которые обычно проявляются в двух формах: когда одно требование можно интерпретировать по-разному и когда разные люди понимают одно и то же требование по-своему. Тестирование требований помогает выявить такие проблемы, хотя полностью исключить двусмысленность невозможно. Важно, чтобы требования были сформулированы однозначно, без жаргона, аббревиатур и неясных фраз, чтобы не возникало различных трактовок.

Пример 1: "Отменить заказ может модератор и администратор сайта".
Несколько интерпретаций этого требованиях являются верными. Программист может решить, что для отмены заказа нужно решение И модератора И администратора сайта, а тестировщик решит, что для отмены заказа достаточно решения только модератора ИЛИ только администратора.
Однозначное требование: "Заказ может быть отменен модератором и администратор сайта. Для выполнения операции достаточно одного из этих сотрудников."

Пример 2: "Сервис должен быть интегрирован с СК."
Что значит СК? Система Криптографии? Сервер Коммуникаций? Система Качества? Служба Консультирования? Что, если в компании есть все эти сервисы?
Однозначное требование: "Сервис должен быть интегрирован с Системой Контроля (СК), предоставляющей разграничение управления доступом.

ВЫПОЛНИМОСТЬ (или "осуществимость").
Выполнимость требований в проекте определяется их возможностью быть реализованными с учетом технических, бюджетных и временных ограничений. Для оценки выполнимости можно использовать инкрементальную разработку и прототипы. Если требование невозможно выполнить, важно учитывать его влияние на проект и принимать решения о его исключении.

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

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

ПРОВЕРЯЕМОСТЬ (или "тестируемость").
Тестируемость требований означает их способность быть проверенными через объективные тест-кейсы, которые ясно показывают правильность реализации. Неполные, несогласованные или двусмысленные требования не поддаются проверке.

Пример 1: "На некоторые товары автоматически применяется скидка 15%."
Неясно, какие именно товары подходят под определение "некоторые", а значит, мы не сможем проверить реализацию этого требования.
Проверяемое требование: "На товары из категории 'Электроника' автоматически применяется скидка 15%."

Пример 2: "Скидка Премиум-пользователя в размере 10% применяется по возможности к заказам пользователя, имеющего статус Премиум."
Неясно, что означает "по возможности" и как проверить наступление или отсутствие этой возможности.
Проверяемое требование: "Скидка Премиум-пользователя в размере 10% автоматически применяется ко всем заказам Премиум-пользователей."

ПРИОРИТИЗИРОВАННОСТЬ (или "упорядоченность").
Требования должны быть упорядочены по важности, стабильности и срочности. Важность определяет, насколько успех проекта зависит от выполнения требования; стабильность показывает, насколько вероятность изменений в требовании мала; срочность влияет на распределение усилий команды по времени. Неверно расставленные приоритеты могут привести к неэффективному распределению ресурсов, выполнению ненужной работы и нарушению сроков.

Пример 1:
"1. Пользователь должен иметь возможность переключаться между светлой и темной темой интерфейса.
2. Система платежей должна быть интегрирована с новым партнером. API партнера может меняться по мере разработки.
3. Пользователь должен иметь возможность просмотреть информацию о своих заказах"

Нарушена упорядоченность по важности и срочности, так как последнее требование намного полезнее для пользователя, чем наличие светлой и темной темы. Нарушена упорядоченность по стабильности, так как интеграция с системой, чья API может изменяться, создает высокую степень неопределенности и риск ненадежной работы функции, что может потребовать значительных доработок и тестирований. Реализацию этого требования можно отложить до релиза стабильной версии API партнером.

Оставшиеся 5 критериев будут разобраны во второй части статьи.