4.11 Критерии для написания текста требований
Независимо от языковых аспектов написания требований, существуют четкие критерии, которым должна удовлетворять формулировка каждого требования. Вкратце эти критерии можно сформулировать следующим образом:
- атомарность: каждое утверждение (формулировка требования) должно представлять собой один элемент иерархии, пригодный для установки связей с ним;
- уникальность: каждое требование должно иметь собственный уникальный идентификатор;
- выполнимость: требование должны быть технически реализуемо в установленные сроки, в рамках выделенного бюджета;
- законность: требование не должно противоречить применимому законодательству;
- ясность: требование должно быть понятно сформулировано (исключать неоднозначное толкование);
- точность: требование должно быть точным и лаконичным;
- проверяемость: должна существовать возможность проверки реализации каждого конкретного требования;
- абстрактность: формулировка не должна навязывать определенные технические решения, характерные для более низких уровней требований (спецификаций).
Дополнительно можно привести критерии, применимые к набору требований:
- полнота: все необходимые требования зафиксированы;
- непротиворечивость: не существует требований, противоречащих друг другу;
- отсутствие избыточности: каждое требование сформулировано только один раз (нет повторов);
- модульность: требования, близкие друг другу по смыслу, содержаться в одном разделе;
- структурированность: наличие ясной и четкой структуры документа с требованиями;
- удовлетворенность: достигнут требуемый уровень покрытия требований связями типа «удовлетворяется (посредством)»
- тестируемость: достигнут требуемый уровень покрытия требований тестами.
Для иллюстрации того, как не надо делать, ниже приводятся два «жутких» примера формулирования требований:
1. Система должна обеспечивать максимальный уровень производительности в течение всего времени работы, за исключением аварийных ситуаций, при которых она должна обеспечивать уровень производительности до 125%, но только если аварийная ситуации не длится более чем 15 минут, - в противном случае система должна уменьшить уровень производительности до 105%; но в случае, если удается достигнуть уровня производительности только 95%, система должна активировать режим «исключительно малого уровня» и поддерживать этот уровень в пределах 10% от начального значения в течение, как минимум, 30 минут.
2. Система должна обеспечивать основные функции текстового редактора, удобные для использования необученным персоналом, и должна работать в условиях «тонкого» Ethernet'а, проложенного по воздушной системе кабельных каналов с интегрированными сетевыми адаптерами, поставляемыми с дополнительными модулями памяти, при необходимости.
Эти примеры иллюстрируют классические негативные ситуации, характерные для разработки требований. Для того чтобы избежать этих ошибок, мы рекомендуем следовать простым правилам:
- избегать хаоса: формулируя требование, необходимо сконцентрироваться на самом важном; требование не должно быть похоже на роман;
- избегать «лазеек»: например, таких выражений, как «если это необходимо», поскольку такие «лазейки» делают требование неоднозначным и зачастую бесполезным;
- избегать размещения более одного требования в один параграф: зачастую, наличие в одном параграфе более одного требования легко определить по наличию союза «и»;
- избегать рассуждений;
- избегать «размытых.» понятий и слов: обычно, в основном, часто, нормально, типично;
- избегать использования неопределенных терминов: например, удобный в использовании, универсальный, гибкий;
- избегать принятия желаемого за требуемое: напр., 100% надежный, приятный для всех пользователей, безопасный, подходящий для всех платформ, не должен никогда ломаться, обрабатывать все неожиданные сбои, быть готов к модернизациям для любых ситуаций, которые могут возникнуть в будущем и т.д.
Анализ первого примера показывает, что вместо одного требования, нужно писать 12. Развивая эту мысль, лучше всего выделить 4 отдельных условия эксплуатации -нормальное, аварийное, аварийное более 15 минут, режим «исключительно малого уровня», - и описать требования для каждого из этих условий.
Обратите внимание на имеющуюся лазейку во втором примере. Совершенно непонятен объем требования. Например, это требование можно интерпретировать и так: «Система должна обеспечивать основные функции текстового редактора ... при необходимости». Так требуется ли, в конце концов, текстовый редактор или нет? Старайтесь избегать таких ситуаций
Э. Халл, К. Джексон, Д. Дик. Разработка и управление требованиями. Практическое руководство пользователя. — 2-е изд. — Telelogic, 2005. — С. 99-101.