Как написать ТЗ? Критерии к тексту требований.

4.11 Критерии для написания текста требований

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

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

Дополнительно можно привести критерии, применимые к набору требований:

• полнота: все необходимые требования зафиксированы;
• непротиворечивость: не существует требований, противоречащих друг другу;
• отсутствие избыточности: каждое требование сформулировано только один раз (нет повторов);
• модульность: требования, близкие друг другу по смыслу, содержаться в одном разделе;
• структурированность: наличие ясной и четкой структуры документа с требованиями;
• удовлетворенность: достигнут требуемый уровень покрытия требований связями типа «удовлетворяется (посредством)»
• тестируемость: достигнут требуемый уровень покрытия требований тестами.

Для иллюстрации того, как не надо делать, ниже приводятся два «жутких» примера формулирования требований:

1.      Система должна обеспечивать максимальный уровень производительности в течение всего времени работы, за исключением аварийных ситуаций, при которых она должна обеспечивать уровень производительности до 125%, но только если аварийная ситуации не длится более чем 15 минут, - в противном случае система должна уменьшить уровень производительности до 105%; но в случае, если удается достигнуть уровня производительности только 95%, система должна активировать режим «исключительно малого уровня» и поддерживать этот уровень в пределах 10% от начального значения в течение, как минимум, 30 минут.

2.      Система должна обеспечивать основные функции текстового редактора, удобные для использования необученным персоналом, и должна работать в условиях «тонкого» Ethernet'а, проложенного по воздушной системе кабельных каналов с интегрированными сетевыми адаптерами, поставляемыми с дополнительными модулями памяти, при необходимости.

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

• избегать хаоса: формулируя требование, необходимо сконцентрироваться на самом важном; требование не должно быть похоже на роман;
• избегать «лазеек»: например, таких выражений, как «если это необходимо», поскольку такие «лазейки» делают требование неоднозначным и зачастую бесполезным;
• избегать размещения более одного требования в один параграф: зачастую, наличие в одном параграфе более одного требования легко определить по наличию союза «и»;
• избегать рассуждений;
• избегать «размытых.» понятий и слов: обычно, в основном, часто, нормально, типично;
• избегать использования неопределенных терминов: например, удобный в использовании, универсальный, гибкий;
• избегать принятия желаемого за требуемое: напр., 100% надежный, приятный для всех пользователей, безопасный, подходящий для всех платформ, не должен никогда ломаться, обрабатывать все неожиданные сбои, быть готов к модернизациям для любых ситуаций, которые могут возникнуть в будущем и т.д.

Анализ первого примера показывает, что вместо одного требования, нужно писать 12. Развивая эту мысль, лучше всего выделить 4 отдельных условия эксплуатации -нормальное, аварийное, аварийное более 15 минут, режим «исключительно малого уровня», - и описать требования для каждого из этих условий.

Обратите внимание на имеющуюся лазейку во втором примере. Совершенно непонятен объем требования. Например, это требование можно интерпретировать и так: «Система должна обеспечивать основные функции текстового редактора ... при необходимости». Так требуется ли, в конце концов, текстовый редактор или нет? Старайтесь избегать таких ситуаций