• законность: требование не должно противоречить применимому законодательству;.

• ясность: требование должно быть понятно сформулировано (исключать неоднозначное толкование);.

• точность: требование должно быть точным и лаконичным;.

• проверяемость: должна существовать возможность проверки реализации каждого конкретного требования;.

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

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

• полнота: все необходимые требования зафиксированы;.

• непротиворечивость: не существует требований, противоречащих друг другу;.

• отсутствие избыточности: каждое требование сформулировано только один раз (нет повторов);.

• модульность: требования, близкие друг другу по смыслу, содержаться в одном разделе;.

• структурированность: наличие ясной и четкой структуры документа с требованиями;.

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

• тестируемость: достигнут требуемый уровень покрытия требований тестами.

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

1.

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

2.

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

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

• избегать хаоса: формулируя требование, необходимо сконцентрироваться на самом важном; требование не должно быть похоже на роман;.

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

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

• избегать рассуждений;.

• избегать «размытых.» понятий и слов: обычно, в основном, часто, нормально, типично;.

• избегать использования неопределенных терминов: например, удобный в использовании, универсальный, гибкий;.

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

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

- и описать требования для каждого из этих условий.

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

Так требуется ли, в конце концов, текстовый редактор или нет? - старайтесь избегать таких ситуаций.

4.12 Заключение.

Один из самых трудных моментов в разработке требований это начало - что называется, «лиха беда-начало».

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

Авторы предлагают использовать следующую «безопасную» последовательность шагов в процессе работы с требованиями:.

• Определите структуру требований и пытайтесь совершенствовать ее в процессе работы с требованиями.

• Фиксируйте (записывайте) требования как можно раньше, даже если они весьма далеки от совершенства.

• Заранее определите атрибуты требований, которые в последующем будут использоваться для классификации и детализации требований.

• Как можно быстрее подготовьте первый вариант требований, для того чтобы стимулировать получение отзывов.

• Постоянно совершенствуйте (улучшайте) требования в процессе работы, удаляя повторения, преждевременные и недозволенные технические решения, противоречивость.

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

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

А для написания (формулирования) требований можно следовать нижеприведенным.

правилам:.

• Используйте простой и прямой (однозначный) язык;.

• Пишите такие требования, которые могут быть проверены;.

• Используйте определенную и согласованную терминологию;.

• В одном требовании формулируйте только одно утверждение.

• Начав работать над одним требованием, постарайтесь закончить с ним прежде, чем переходить к другому.