Требования к требованиям, или свойства качественных требований
Полнота
Требование содержит всю необходимую информацию, ничто не пропущено по соображениям «это и так всем понятно».
Типичные проблемы
- «Пароли должны храниться в зашифрованном виде» - каков алгоритм шифрования?
- «Экспорт осуществляется в форматы PDF, PNG и т.д.» — что мы должны понимать под «и т.д.»?
- «См. выше» вместо «см. раздел 123.45.b»
Атомарность
Требование описывает одну ситуацию и не может быть разбито на части без потери смысла.
Типичные проблемы
- «Кнопка “Restart” не должна отображаться при остановленном сервисе, окно “Log” должно вмещать не менее 20-ти записей о последних действиях пользователя» — в одном предложении описаны разные элементы интерфейса в разных контекстах.
- «Если пользователь подтверждает заказ и редактирует заказ или откладывает заказ, должен выдаваться запрос на оплату» — описаны три разных случая, и это требование стоит разбить на три отдельных во избежание путаницы.
- «Когда пользователь входит в систему, ему должно отображаться приветствие; когда пользователь вошел в систему, должно отображаться имя пользователя; когда пользователь выходит из системы, должно отображаться прощание» — все три ситуации должны быть описаны отдельно и более детально.
Непротиворечивость
Требование не содержит внутренних или внешних противоречий с другими требованиями, документами или элементами системы.
Типичные проблемы
- «После успешного входа в систему пользователя, не имеющего права входить в систему…» — тогда как он успешно вошёл в систему, если не имел такого права?
- Противоречия между двумя и более требованиями, между таблицей и текстом, рисунком и текстом, требованием и прототипом и т.д. (например: «712.a Кнопка “Close” всегда должна быть красной» и «36452.x Кнопка “Close” всегда должна быть синей»).
Недвусмысленность
Требование формулируется ясно и однозначно, без использования жаргона, аббревиатур или расплывчатых выражений. Старайтесь избегать таких слов, как: много, мало, часто, редко, эффективно, большой, быстро, легко, несколько.
Типичные проблемы
- Использование терминов или фраз, допускающих субъективное толкование: «приложение должно поддерживать передачу больших объемов данных» — насколько больших?
- «В случае необходимости оптимизации передачи больших файлов система должна эффективно использовать минимум оперативной памяти, если это возможно»
Выполнимость
Требование должно быть реализуемым в рамках бюджета и сроков разработки проекта.
Типичные проблемы
- «Система поиска должна заранее предусматривать все возможные варианты поисковых запросов и кэшировать их результаты».
- «Анализ договоров должен выполняться с применением искусственного интеллекта, который будет выносить однозначное корректное заключение о степени выгоды от заключения договора».
Актуальность
Требование необходимо для успеха проекта и соответствует текущим условиям. Требование имеет приоритет, например, по MoSCoW.
Типичные проблемы
- Требование было добавлено «на всякий случай», хотя реальной потребности в нём нет.
- Ошибки приоритета требования.
- Требование устарело.
Прослеживаемость
Требования должны иметь атрибуты, позволяющие осуществлять трассировку требований и вносить изменения. Например: номер/ID, приоритет, владельца, ответственного.
Корректность
Требование должно иметь правильный уровень детализации и не должно содержать ошибок, в т.ч. логических.
Типичные проблемы
- Плохое оформление и ошибки в тексте.
- Слишком глубокая детализация требования на уровне бизнес-требований или недостаточная детализация на уровне требований к продукту.
- «Пользователь должен быть в состоянии отправить сообщение» — увы, мы не можем влиять на пользователя.
- «В случае, если разрешение окна составляет менее 800x600…» — разрешение есть у экрана, у окна есть размер.
Статьи по теме
- Требования (Requirements) — QA_Bible
- Критерии качества требований — Наталья Чаусова
- О критериях качества требований — Art of Business Analysis
Документы
Стандарт IEEE 830-1998 (SRS) на русском