16. Структурирование документов, содержащих требования. Критерии для написания текста требований. Связанность и согласованность требований.

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

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

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

Обычно документы имеют иерархическую структуру с разделами и подразделами нескольких уровней. Иерархии представляют собой структуры, удобные для классификации, и одним из способов структурирования документа является использование системы заголовков разделов для категоризации пунктов требований. При таком подходе положение пункта требований в документе соответствует основной или первичной классификации. (Вторичные и вспомогательные классификации могут быть организованы с помощью ссылок на другие разделы или с помощью атрибутов.) В главе 3 были приведены примеры того, как часто с целью анализа систем при моделировании используются иерархии.

Примеры:

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

декомпозиция состояний в диаграммах состояний.

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

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

Помимо языковых аспектов, существуют определённые критерии, которым должно отвечать каждое описание требования. Краткий перечень этих критериев приведен ниже:

Ниже приведены два примера неприемлемых формулировок требований, взятые из практики:

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

2. Система должна предоставлять возможности обработки текстов, должна быть удобной для неподготовленного персонала и работать в среде локальной сети Ethernet, реализованной аппаратными средствами в виде системы воздушных кабельных каналов с интегрированными сетевыми адаптерами, устанавливаемыми в каждую систему, с добавлением дополнительных модулей памяти при необходимости. Эти примеры наглядно показывают проблемы, постоянно встречающиеся в практической деятельности. При определении требований необходимо избегать следующих критических ошибок:

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