Требования к требованиям, или свойства качественных требований

✅ Полнота. Требование содержит всю необходимую информацию, ничто не пропущено по соображениям «это и так всем понятно».

⛔️ Типичные проблемы:
➖ «пароли должны храниться в зашифрованном виде» - каков алгоритм шифрования?
➖ «экспорт осуществляется в форматы PDF, PNG и т.д.» — что мы должны понимать под «и т.д.»?
➖ «см. выше» вместо «см. раздел 123.45.b»

✅ Атомарность. Требование описывает одну ситуацию и не может быть разбито на части без потери смысла.

⛔️ Типичные проблемы:
➖ «кнопка “Restart” не должна отображаться при остановленном сервисе, окно “Log” должно вмещать не менее 20-ти записей о последних действиях пользователя» — в одном предложении описаны разные элементы интерфейса в разных контекстах
➖ «если пользователь подтверждает заказ и редактирует заказ или откладывает заказ, должен выдаваться запрос на оплату» — описаны три разных случая, и это требование стоит разбить на три отдельных во избежание путаницы
➖ «когда пользователь входит в систему, ему должно отображаться приветствие; когда пользователь вошел в систему, должно отображаться имя пользователя; когда пользователь выходит из системы, должно отображаться прощание» — все три ситуации должны быть описаны отдельно и более детально

✅ Непротиворечивость. Требование не содержит внутренних или внешних противоречий с другими требованиями, документами или элементами системы.

⛔️ Типичные проблемы:
➖ «после успешного входа в систему пользователя, не имеющего права входить в систему…» — тогда как он успешно вошёл в систему, если не имел такого права?
➖ Противоречия между двумя и более требованиями, между таблицей и текстом, рисунком и текстом, требованием и прототипом и т.д. (например: «712.a Кнопка “Close” всегда должна быть красной» и «36452.x Кнопка “Close” всегда должна быть синей»

✅ Недвусмысленность. Требование формулируется ясно и однозначно, без использования жаргона, аббревиатур или расплывчатых выражений. Старайтесь избегать таких слов, как: много, мало, часто, редко, эффективно, большой, быстро, легко, несколько…

⛔️ Типичные проблемы:
➖ Использование терминов или фраз, допускающих субъективное толкование: «приложение должно поддерживать передачу больших объемов данных» — насколько больших?
➖ «В случае необходимости оптимизации передачи больших файлов система должна эффективно использовать минимум оперативной памяти, если это возможно»

✅ Выполнимость. Требование должно быть реализуемым в рамках бюджета и сроков разработки проекта.

⛔️ Типичные проблемы:
➖ «система поиска должна заранее предусматривать все возможные варианты поисковых запросов и кэшировать их результаты»
➖ «анализ договоров должен выполняться с применением искусственного интеллекта, который будет выносить однозначное корректное заключение о степени выгоды от заключения договора»

✅ Актуальность. Требование необходимо для успеха проекта и соответствует текущим условиям. Требование имеет приоритет, например, по MoSCoW.

⛔️ Типичные проблемы:
➖ Требование было добавлено «на всякий случай», хотя реальной потребности в нём нет
➖ Ошибки приоритета требования
➖ Требование устарело

✅ Прослеживаемость. Требования должны иметь атрибуты, позволяющие осуществлять трассировку требований и вносить изменения. Например: номер/ID, приоритет, владельца, ответственного

✅ Корректность. Требование должно иметь правильный уровень детализации и не должно содержать ошибок, в т.ч. логических

⛔️ Типичные проблемы:
➖ плохое оформление и ошибки в тексте;
➖ слишком глубокая детализация требования на уровне бизнес-требований или недостаточная детализация на уровне требований к продукту);
➖ «пользователь должен быть в состоянии отправить сообщение» — увы, мы не можем влиять на пользователя
➖ «в случае, если разрешение окна составляет менее 800x600…» — разрешение есть у экрана, у окна есть размер

📎 Статьи по теме
1. Требования (Requirements) — QA_Bible
2. Критерии качества требований — Наталья Чаусова
3. О критериях качества требований
— Art of Business Analysis

📄 Документы
Стандарт IEEE 830-1998 (SRS) на русском

#требования