При освоении такой дисциплины как управление требованиями и использования таких инструментов как RaQuest и Enterprise Architect, столкнулся с такой феноменологической проблемой.

Вариант использования описывает некоторую функциональность системы и таким образом является частью требований к системе.

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

Однако можно ли утверждать, что одно требование реализует другое? Мне думается, что нет.

Другое дело утверждать, что требование реализует ВИ. В этом есть смысл, поскольку ВИ - есть цель, и требование может реализовать цель. Цель - как нам ранее показал Boatman, есть образ результата, т.е. решения. Получается, что в ВИ  скрыта двойственность - это и требование, и часть решения.

Проблема возникает в осмыслении того как работать с требованиями при их графическом описании (если это вообще стоит делать). Можно ли манипулировать с ребованиями как с классами и какие типы связей между ними допустимы в таком случае...

Может имеет смысл посмотреть в сторону SysML?

Может прояснишь свою мысль?

Может прояснишь свою мысль?

Если ты хочешь строить Д требований, то имеет смысл смотреть в сторону SysML

Если ты хочешь строить Д требований, то имеет смысл смотреть в сторону SysML

Саша непонятно зачем применять уже еще и SysML? Нужно таки учесть, что данная нотация все-таки не включена в case средства по умолчанию...

Сергей, построение бороды требований - не самоцель.
Если под бородой ты понимаешь иерархию, то она великолепно строится на базе агрегаций.
Да я понимаю, что есть матрица требований в ЕА, есть матрица требований в Раквесте.
Я еще глубоко не изучал, чем они отличаются, но в раквесте матрица трассировки затрагивает только зависимости меду требованиями, но не агрегации или реализации.


добавлю часть моего миропонимания требований.

По определению требование некое условие или возможность, которым должна удовлетворять система. По ГОСТ это исходные данные на основании, которых строится ИС или ПО.

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

Требования могут зависить один от другого, находиться в определенном отношении (агрегироваться). Однако мне не понятна мысль, что одно требование обобщает другое (в смылсе генериализации) или одно требование реализует другое.

ЕА действительно позволяет строить разные матрицы требований с учетом любого типа связи. Раквест часть ЕА все-таки и предназначен для более удобного управления списками требований. Однако матрица требований (трассировки) предусматривает
только связи зависимости. Что это - упущение Раквест? Политика раквест? Разделене обязаностей между раквест и ЕА?

Если ты посмотришь раквест, то увидишь, что он создает и видит только связи типа Realize.

Сергей, а так ли.

Рассмотрим связку RaQuest 3.0 и  EA 7.0

формирую список требований с некоторой вложенной структурой.
требов1
  требов1.1
  требов1.2
требов2
  требов2.1
  требов2.2
    требов2.2.1
Переходим в матрицу требований (видим первый рисунок)

Запустим ЕА из-под RaQuest
  добавим в созданный пакет Requirements диаграмму требований и вытащим все требования на нее, получим рисунок 2

Как мы видим ЕА автоматически сформировал связи-зависимости. Дабы убедиться, что я не вру, щелкаем по связи и смотрим ее свойства (3 рисунок)

Добавляем связь реализации между какими-то требованиями (например как на рисунке 4)
Сохраняем изменения в ЕА, перегружаем Раквест и переходим на следующее сообщение (количество вложений только 4)

продолжение предыдущего поста.

В раквесте смотрим матрицу Требований и видим, что она ничуть не изменилась. (рисунок 1 (или 5 в нашей нумерации от предыдущего поста)

Если продолжить эксперимент и например удалить зависимость между требов2.2 и требов2.2.1, а от требов2.2.1. провести агрегацию к требов2.1, сохранить и перегрузить раквест - ничего не изменится, а почему? потому как в ЕА сохранилась вложенная структура требов2.2.1 в требов2.2.
Если же взять и в ЕА переместить требов2.2.1 из требов2.2 в требов2.1 сохранить и перегрузить раквест - на лицо все изменния и в структуре иерархии и в матрице зависимостей требований (см рис 2 он же 6)
Обратите внимания что нет трасировки от 2.2.1 к 2.1 которая подразумевается вложенностью, вчем дело? просто я же удалял связь зависимость. Если теперь ее востановить получим (рис 3 он же 7)

Делаем вывод.
Когда мы формируем вложенную структуру в раквесте, а затем вызываем ЕА и перетаскиваем требования на диаграмму, связи -зависимости, обусловленные вложенностью, появляются автоматически. Однако если не нарушая вложенность в ЕА удалить зависимость, и затем перейти в раквест, то мы увидим сохранение структуры, но отсутствие трассировки в матрице требований.
Если эту трассировку в Раквесте восстановить (технологией драг-н-дроп или прямо в матрице) и перегрузить ЕА, то все появится вновь, Можно сделать и наоборот - восстановить связь в Еа и перегрузить Раквест, чтобы убедится в восстановлении матрицы трассировки требований.

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

Далее, если в ЕА добавить на диаграмму требование (нумерция кстати соблюдается) и разместить его в нужном месте (скажем создадим требов1.1.1 и поместим его в требов1.1.) сохранить и перегрузить Раквест - получим вложенное, но не отрассированное требование. Чтобы видить трассировку связанную с вложенностью приходится в ЕА или Раквесте задать ее явно

Думается пора писать в Раквест. Ктобы взялся все это культурно перевести

Разобраться с тонкостями позволяет Иерархия в ЕА CTRL+SHIFT+4 там уже можно увидеть вразумительные пояснения, кто кому принадлежить, кто от кого зависит, кто кого реализует или просто кто с кем связан. Правда не совсем улавливаю в чем смысл связан и как он отличается в данном случает от зависит. Если требование А связано (ассоциацией) с требованием В, разве это не означает что требование а или требование В зависят один от другого. Просто стрелка зависимости показывает кто от кого завивит, а ассоциация получается говорит что оба зависят друг от друга?

Согласен, немного погорячился. Когда осваивал, связи между требованиями выпали из виду. Но для Use Case и других элементов UML тащатся только связи Realize, при том, что считается, что элемент реализует требование ,наоборот быть не может. Для связей требование-требование тащится depend и его разновидности

Сережа, наконец мы добрались к сути моего поста:)
Долго я подбирался чтобы передать то, что хотелось передать

ВИ - вроде и требование, да какое-то иное, вроде и UML элемент и тут он явно к месту.

Я проверил по быстрому и работу с вариантами использования. Как? Поясняю

Делаем в ЕА несколько ВИ на скорую руку сохраняем

Идем в Раквест. Импортируем эти самые ВИ

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

Суть моих разочарований в raquest в том, что на матрице не виден тип связи и при редактровании матрицы задается только один из предустановленных depend или realize, возможно, просто, у него своя идеология, которую надо понять.

Именно. Тут нужно конечно осознавать что важно для матрицы трассирвки. Вид связи или наличие зависимости.
По сути Раквест являясь надстройкой над ЕА, его таки не заменяет а в чем-то дополняет. А вот тонкости смотреть требуется в ЕА, хотя поскольку раквест понимает токма зависимости (если не учитывать uml items) то вопрос а почему? не потому ли, что неважна связь акромя зависимости - то есть функциональная, а не структурная?