23. Трассировка требований. Проектная документация. Элементарные связи. Анализ расширенных связей. Параметры анализа связей. Трассировка требований.

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

Как показывает анализ, наиболее важными возможностями, необходимыми для достижения прослеживаемости, являются:

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

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

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

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

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

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

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

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

Доказательство выполнения требований

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

Для улучшения ситуации полезно представить доказательство выполнения (удовлетворения) (satisfaction argument) для каждого требования пользователя. Простая прослеживаемость, демонстрируемая на рис. 7.1, даёт информацию только о том, что три требования к системе играют какую-то роль при доказательстве выполнения требований, но не содержит никаких сведений о том, в чем состоит это доказательство.

Расширенная прослеживаемость представляет собой способ получения доказательства выполнения требования. Обоснование выглядит как отдельный пункт, размещённый между требованием пользователя и соответствующими требованиями к системе, как показано на рис. 7.3.

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

конъюнкция (&) означает, что все перечисленные требования к системе обязательно должны участвовать в доказательстве выполнения требования пользователя;

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

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

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

Каждому требованию высокого уровня ставится в соответствие единственное описание обоснования его выполнения или стратегии, отображаемое в виде атрибута, а несколько требований более низкого уровня могут быть связаны с ним отношением типа «многие ко многим». рис 7.10 Здесь доказательства выполнения требований могут быть структурированы на нескольких уровнях: главное обоснование прикрепляется (как атрибут или как включаемое звено в связи «определяет») к устанавливаемому требованию, а иерархия дополнительных обоснований начинается с главного обоснования. Требования более низкого уровня связаны с дополнительными обоснованиями через отношение «соответствует». Всё это показано на рис. 7.11

Проектная документация.

Теперь рассмотрим пример одного из типов информации, которая может быть собрана в проектном документе. На ряде рисунков показаны фрагменты, взятые из документа «Анализ потребностей», где приведены модели системы приёмки багажа в области проблем. Эта модель занимает место между документами «Описание потребностей» и «Требования заинтересованных сторон» и использует версию языка UML2 для представления результатов анализа в наглядной форме.

Как правило, выделяют следующие типы информации:

концепции – диаграмма классов языка UML используется для определения концепций в области проблем и связей между ними. Каждая концепция является классом UML, а каждая связь – отношением типа «ассоциация» языка UML. Оба элемента используются в проектном документе содержащем текстовые описания концепций или связей. На рис. 7.13 показан пример применения диаграмм классов для системы приёмки багажа. Символы слева от каждого пункта обозначают соответствие данного пункта UML-элементу в модели;

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

статический контекст – цель этого раздела – определить контекст, в котором существует данная система приёмки багажа. Сама система моделируется как класс на диаграмме классов вместе с другими классами, представляющими все окружающие и объемлющие системы. Связи между этими системами моделируются с использованием агрегирования и ассоциаций. И в этом случае каждый класс и соответствующая ассоциация включаются в документ с сопровождающим текстовым описанием (рис. 7.15);

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

Метрики прослеживаемости

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

Если сосредоточиться на связях «удовлетворяет/удовлетворяется» и продвигаться вниз по уровням требований, то можно обнаружить три заслуживающих внимания измерения прослеживаемости:

7.11.1. Широта

Широта непосредственно связана с охватом или покрытием, поэтому она является метрикой этапа. Как было сказано в главе 1, покрытие или охват может использоваться для измерения прогресса процессов, формирующих прослеживаемость на одном этапе. Здесь внимание сосредоточено на единственном уровне, и измеряется степень покрытия, то есть количество требований, охваченных требованиями смежного уровня, лежащего выше или ниже (или «соседнего» уровня, если рассматривается процесс проверки соответствия).

7.11.2. Глубина

Глубина определяет количество уровней, на которые распространяется прослеживаемость вверх или вниз, начиная с рассматриваемого уровня, то есть это глобальная метрика. Отдельное приложение может иметь отношение к определению источников требований самого нижнего уровня. Сколько всего требований к компоненту было фактически выведено из требований заинтересованных сторон, и для какого количества этих требований источники определены где-то в проектном решении?

7.11.3. Развитость

Развитость – более интересная метрика. Она связана с потенциальным воздействием изменений. Для скольких требований на нижних уровнях установлены связи с одним требованием самого верхнего уровня?

Рассмотрим рис. 7.18, на котором изображены четыре различные ситуации. В случае «а» одно требование удовлетворяется единственным требованием следующего, более низкого уровня. Здесь фактор развитости равен 1. В варианте «б» одному требованию соответствует 6, таким образом, фактор развития равен 6. Что можно сказать о различиях между этими двумя требованиями? Возможны следующие ответы:

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

требование (б) по своей сущности более сложно, чем (а), следовательно, ему нужно уделить особое внимание;

изменение требования «б» будет иметь большее воздействие, чем изменение требования «а», поэтому требованию «б» следует уделить особое внимание.

ну а вообще можно смотреть вопрос 22, там то же самое