Форум Сообщества Аналитиков
Дисциплины => Системный Анализ и Требования => Тема начата: bas от 22 Октября 2008, 11:49:16
-
Правильнее трассировать от Пользовательских Требований к Бизнес Требованиям или наоборот?
Т.е. меня интересует направление трассировки!
-
Т.е. меня интересует направление трассировки?
Ну это я не знаю :)
-
Спасибо Денис :) Исправил ...
Просто на последнем семинаре Виталий обмолвился, что он трассирует от БВИ к СВИ. У меня же противоположное мнение :)
-
Трассировка - это направление от источника к цели, те мы трассируем от БВИ (источник) к СВИ (цель), или по другому сказать трассируем БВИ на СВИ.
А вообще, по-моему нет жесткого правила в какую именно сторону стрелочку показывать, вот отрывок статьи про трассировку
There is some question as to which direction the arrows should go: whether from lower level to higher level or from higher to lower level. Even the two examples in RequisitePro use different guidelines. The answer is that it doesn't matter, as long as you use them consistently across the project.
Я понимаю трассировку именно от верхнего уровня на нижний. Но это мое ИМХО, я так привык работать.
-
Прочитав статейку The Role of Requirements Traceability in System Development (http://www.ibm.com/developerworks/rational/library/content/RationalEdge/sep02/TraceabilitySep02.pdf), я понял, что Виталий был прав. Т.е. БТ трассируются (влияют) на ПТ и т.д.
-
Я тоже вставлю свой алтын.
Трассировка или прослеживаемость. Происходить от английского trace III.
Среди переводов мы видим:
следовать, идти по следам
проследить, установить
прослеживаться, восходить
Такми образом прослеживаемость может быть разного направления как прямого, так и обратного.
Направление прослеживаемости можно понять относительно некоего требования или артефакта смотри вложение
-
Такми образом прослеживаемость может быть разного направления как прямого, так и обратного.
В английском есть два понятия trace to (трассируеся на) и trace from (следует из)
Пример, пусть есть фича (F1) и ВИ (UC1)
Если мы понимаем, что из F1 следуют вариант использования UC1, то мы делаем так:
1. F1 --trace to--> UC1 (говорим: "фича1 трассируется на ВИ1")
2. UC1 <--trace from-- F1 (говорим: "ВИ1 следует из фичи1")
Следовательно, направление трассировки, это лишь правила чтения связей.
ЗЫ Еще не нужно путать зависимости между требованиями с трассировкой
-
Так все-таки трассировка - это прослеживаемость одно через другое, или же все-таки вытекание одного из другого. Если последнее - то, это, по-моему, и есть зависимость . Нет?
-
Правильнее трассировать от Пользовательских Требований к Бизнес Требованиям или наоборот?
Т.е. меня интересует направление трассировки!
IMHO направление трассировки не имеет значения. Раз бизнес-требование как-то связано с системным - понятно, что бизнес-требование является источником системного.
Сложных случаев с обратной связью с заинтересованными лицами по результатам ревью системных требований я не учитываю, т.к. считаю, что в БД требований это фиксировать не следует.
-
а у Лиффингуэлла есть интересная оговорка про возможность типизации traceability-отношений (является частью, унаследовано из, тестируется..). В этом случае гибкость выборок из базы увеличиваются, но модель усложняется, конечно. И у связи, видимо, появляется направление...
Кто-нибудь работал на практике с такими игрушками? :)
Кстати, а trace --- транзитивное отношение?
PS
Прошу прощения за некромансию тем :)
-
В SysML используются разные типы отношений на Д Требований:
http://www.oose.de/downloads/sysml.overview.oose.pdf
Тут я не знаю Лиффингуэлл украл у SysML идею или наоборот. ИМХО на практике этим мало кто пользуется.
trace я обычно перевожу как трассировка.
-
В теме [Термин] trace (http://www.uml2.ru/forum/index.php?topic=798.0) было обсуждение перевода данного термина.
-
Тут я не знаю Лиффингуэлл украл у SysML идею или наоборот. ИМХО на практике этим мало кто пользуется.
Ага, понятно, ну он тоже, в общем, говорит о редкой необходимости.
trace я обычно перевожу как трассировка.
Спасибо, это понятно, я про другое немножко.
Трассировка А->B и B->C предполагает же A->C получается?
В смысле, при изменении бизнес-требования (А), влияющего на системное (Б) impact будет включать все, что трассируется к Б?
При этом трассировка не симметрична, изменение UC может вызывать изменение соответствующего TC, но не наоборот.
Верно ли это на практике?
-
Хорошо бы посмотреть все связанные Требования с данным, как в низ так и в верх. Т.к. на самом деле более детальные Требования могут возникать из-за изменения БТр, но Вам про это никто не сказал. На практике чаще всего идет проверка сверху вниз.