которые воплощаются как.

• организация бизнеса и бизнес-процессов.

В контексте системного проектирования интерес может фокусироваться на том, как:.

• пользовательские требования (stakeholder requirements).

удовлетворяются.

• системными требованиями,.

которые разделяются на.

• подсистемы,.

которые реализуются как.

• компоненты.

Использование связей может принести следующие выгоды:.

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

• Возможность оценить влияние изменений. Существование связей между требованиями дает возможность проводить разного рода анализ влияния вносимых изменений.

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

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

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

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

Программные средства поддержки работы с требованиями обычно позволяют создавать связи путем «перетаскивания одного параграфа документа на другой» (“drag-n-drop”). Связи между требования выглядят как гиперссылки на web страницах, но в отличие от них должны иметь возможность прослеживаться в любом направлении. На рис. 1.6. показано, например, как выглядят связи между различными уровнями требований, а также связи и между требованиями и соответствующими тестами.

Рис. 1.6 Связи между требованиями.

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

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

• Очень часто это соответствует также и правам на владение информацией: одному человеку принадлежат исходящие из документа связи, другому - только входящие.

Для поддержки процесса работы с требованиями используются различные методы анализа связей между требованиями (см. таблицу 1.3).

Таблица 1.3 Методы анализа связей требований

Анализ влияния дает возможность оценить, на какие другие элементы проекта (нижнего уровня) повлияет внесение изменения в данный конкретный элемент (см. рис. 1.7).

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

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

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

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

Анализ покрытия также применяется для того, чтобы измерить прогресс работы - то, насколько системные инженеры продвинулась в удовлетворении требований пользователей. Подразумевается, что системные инженеры разрабатывают системные требования, отвечающие требованиям пользователей, или, как еще говорят, «покрывающие» их.

Рис. 1.7 Анализ влияния и анализ последствий.

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

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

Тот же самый принцип может быть использован для измерения прогресса разработки планов тестирования. Процент готовых планов тестирования может быть определен как процент покрытия требований тестами.

Использование анализа покрытия в этих двух измерениях проиллюстрировано на рис. 1.8.

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

Более подробно связи и их анализ рассмотрены в Главе 7.