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

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

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