Создание и анализ связей между требованиями

из "Разработка и управление требованиями "

В контексте разработки требований, создание и анализ связей необходимы, в первую очередь, для понимания того, как требования высокого уровня - общие цели, задачи, пожелания, предполагаемые ожидания, нужды и т.п. - трансформируются в требования низкого уровня. Следовательно, в основном, связи нужны между различными уровнями информации. [c.12]
Связи между требованиями обычно имеют тип многие ко многим . Одно требование нижнего уровня может быть связано с несколькими требованиями более высокого уровня, и наоборот. В простейшем же случае связи могут устанавливаться между разными требованиями, но одного уровня. [c.13]
Для поддержки процесса работы с требованиями используются различные методы анализа связей между требованиями (см. таблицу 1.3). [c.14]
Анализ влияния дает возможность оценить, на какие другие элементы проекта (нижнего уровня) повлияет внесение изменения в данный конкретный элемент (см. рис. 1.7). А поскольку зачастую влияние одного элемента на другие носит относительный характер, поэтому каждый раз при внесении изменения, если это необходимо, проводить более детальный анализ того, затронет ли данное изменение другие элементы проекта или нет и, если затронет, то насколько сильно. [c.14]
Анализ последствий работает в противоположном направлении анализу связей. Анализируются элементы нижнего уровня, например, содержание требования, часть спецификации или результат теста, а затем с помощью связей проверяется его соответствие одному из элементов более высокого уровня. [c.14]
Элементы нижних уровней, если они не имеют никаких исходящих наверх связей, вероятно, лишь увеличивают затраты и не приносят никакой пользы. [c.14]
Анализ покрытия используется для анализа входящих связей, для того чтобы проверить, что все требования высокого уровня связаны со спецификациями на более низких уровнях и тестами. Отсутствие таких связей свидетельствует о том, что требование не будет удовлетворено (выполнено) или протестировано. Наличие связей, само по себе, не дает гарантии, что требование будет удовлетворено и протестировано. Для того, чтобы убедиться в этом необходимо приложить талант, знания и опыт проектировщика системы. [c.14]
Анализ покрытия также применяется для того, чтобы измерить прогресс работы - то, насколько системные инженеры продвинулась в удовлетворении требований пользователей. Подразумевается, что системные инженеры разрабатывают системные требования, отвечающие требованиям пользователей, или, как еще говорят, покрывающие их. [c.14]
На любом этапе разработки системных требований процент их готовности может быть определен как процент покрытия пользовательских требований системными. Это очень удобно для руководящего персонала, поскольку в любой момент времени дает возможность контролировать прогресс (процесс развития событий) даже на самых ранних стадиях разработки. [c.15]
Тот же самый принцип может быть использован для измерения прогресса разработки планов тестирования. Процент готовых планов тестирования может быть определен как процент покрытия требований тестами. Использование анализа покрытия в этих двух измерениях проиллюстрировано на рис. 1.8. [c.15]
Рассмотренные типы анализа связей позволяют сделать вывод о том, что связи являются, с одной стороны, - очень простой, а с другой стороны, - ключевой концепцией процесса работы с требованиями. [c.15]
Более подробно связи и их анализ рассмотрены в Главе 7. [c.15]

Вернуться к основной статье