сообщение устарело

Цитирую:
"В таком (графическом) виде применима при очень небольшом количестве требований и взаимосвязей, оптимально - на уровне презентации. При детализации превращается в нечитаемую паутину."
"Для анализа нужно работать с полной схемой. "

Денис, Вы предлагаете людям работать с полной схемой на ватмане?
Естественно, для работы с трассировкой нужен нормальный инструмент, потому что связей много и нужно работать со срезами - фильтрами, представлениями, чтобы иметь возможность провести качественный анализ. "Рисовать" каждое представление отдельно просто не реально. Эти представления должны генерироваться автоматически.

Я ничего не предлагаю. У вас какие-то галлюцинации. Я лишь спрашивал, где было упоминание необходимости инструментов. Нигде выше упоминания не было.

Учите матчасть.

1. Сергей НЕ рисовал матрицу трассировки. Денис, Вы не в состоянии отличить граф от матрицы?

Перечитайте ещё раз, что я написал. Я не говорил, что он нарисовал. Я говорил, что он сказал, что нарисовал.

Учите матчасть.

3. "Так что стрелками можно пренебречь."
Учите матчасть, там так пытают :-)  Вас не смущают стрелки на всех матрицах трассировки во всех известных инструментах?

У Сергея похоже есть тезис про то, что трассировки всегда двусторонние. Я подожду, пока он сам раскроет.

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

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

Насчет того, что IDEF0 устарел или там его вытеснили - это все сказки.

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

Хватит перевирать.

На уровне слайда такую схему хорошо делать, если вы собираетесь кому-то что-то втюхать. Ибо для "улучшения" восприятия, вы уберете все неприятные моменты.

Да, если цель втюхать. Или нет, если цель противоположная - попытаться отговорить от опрометчивого шага.

Для анализа нужно работать с полной схемой. И проблема тут не в том, что она нечитаема. Читаема, просто времени нужно несколько больше.

Теоретически - соглашусь. Более-менее грамотно отрисованное вполне можно читать, было бы время. Но практически, схемы из 200+ элементов и 500+ связей не читают даже те технари, для которых они предназначены. Проверял на моделях БД неоднократно. Пугается такого клубка человек, и уходит в оборону.

Самому для себя - тоже бывает полезно, да. Но пока получается держать их в уме, держу в уме. Пусть даже ценой некоторого количества субъективных косяков. Ибо сам ленив до безобразия, и не смогу себя заставить регулярно актуализировать подобные графы.
Плюс еще один момент. Эти схемы по природе своей минимум черытехмерные. При проекции "на бумагу", получается, теряем от двух измерений. Потери можно компенсировать, нагрузив проекцию дополнительными элементами, но это усложнит ее визуальное восприятие. Соответственно, в результате имеем некий ситуационный срез исходной схемы, по которому в общем случае восстановить полную картину не представляется возможным.

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

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

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

Так точно. Ибо никто не хочет не только читать, но и системно заставлять читать других.

Второго сотрудника такой квалификации ваша фирма себе позволить не может." Если нужен пример, он есть у меня. Фирма 5000+ сотрудников.

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

Сравнивать BPMN c точки зрения трассировки требований IDEF0 бесмысленно. Одна из ключевых задач трассировки - это трассировка нефункциональных требований к функциональном, у BPMN, насколько я знаю, просто нет выразительных средств для этого, в то время как для IDEF0 это просто "нативное" состояние.

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

Безусловно BPMN не является средством конфигурационного управления, как IDEF0. Тем не менее ровно настолько BPMN является процессной нотацией и позволяет зафиксировать в процессе контекст взаимодействия пользователя с системой, настолько мы можем осуществить трассировку.

И IDEF0 и BPMN требуют зафиксировать границы процесса и цель моделирования. Управление viewpoint в BPMN не такое явное, как в IDEF0, но тем не менее свои критерии детализации описания тоже присутствуют.

Для каждой activity на BPMN диаграмме можно указать исполнителя, для процесса целиком желательно выделить его владельца. На схемке во вложении мы зафисировали активность , ассоциированную с Системой.

Смысл стрелок в BPMN и IDEF0 разный (в BPMN это поток управления, а в IDEF все определяется тем , куда пришла стрелка). То , для чего в IDEF0 отведено три типа входящих стрелок и один исходящий в BPMN отражается только направленной и ненаправленной ассоциацией.

Тем не менее связь системы как с активностью, ее ассоциациями, так и с процессом в целом устанавливается. А если есть связь, значит возможна и  трассировка. 

Несомненным преимуществом IDEF0 является жесткость декомпозиции. Все связи декомпозируемого процесса необходимо пробросить вниз (или наоборот вытащить наверх из декомпозиции) или осуществить туннелирование.
Естественно BPMN не заставляет так строго работать с ассоциативными связями - декомпозиция осуществляется только относительно потока управления.

Поэтому как только мы зафиксировали факт взаимодействия с системой в BPMN мы тут же вынуждены менять нотацию и само это взаимодействие описывать через use case или другими видами поведенческих диаграмм.

В IDEF0 необходимости менять нотацию нет .

В общем то это и определяет применимость нотаций: нужна глубокая декомпозиция - используем IDEF0, нужны события, оркестровки , хореографии или интуитивно понятное отображение БП - тогда BPMN. Но и ту, и другую нотацию можно использовать для трассировки.

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

Я таки прошу посторонних вещей в форуме не писать под угрозой расстрела всякого товарища с лишением прав.

Пожалуйста, не переходите на личности и не опускайтесь до оскорблений.

Григорий, Humbert, Леонид, спасибо за конструктивное обсуждение.

Некий итог.
1. Я кажется понял, где мы с Григорием разошлись в терминологии. Я имел ввиду, что зависимости могут быть и в другую сторону. И тогда возможно появление петель положительной обратной связи.
2. Данная диаграмма призвана ответить на вопрос "Why" (почему, зачем), причем, скорее, "Почему". В этом смысле она не конкурирует за место под солнцем с диаграммами отвечающими на вопрос "Как".
3. Теоретически она полезна.
4. Практическое ее применение сильно ограничено причинами, указанными Humbert и Леонидом. Даже не знаю чьи формулировки мне нравятся больше.

Есть ли от нее польза. Да есть. С помощью нее можно демонстрировать студентам зависимость изменчивости требований от их уровня.  Предупредить их:
1. Если вы вынуждены использовать ТЗ как контракт, то постарайтесь не писать туда требования третьего уровня. Пишите второго уровня и как можно более высокого. Кстати. Показывать это ТЗ программистам совершенно необязательно.
2. Для программистов лучше писать на третьем уровне.

PS. Другие диаграммы предлагаю обсуждать в других ветках.

1. Если вы вынуждены использовать ТЗ как контракт, то постарайтесь не писать туда требования третьего уровня. Пишите второго уровня и как можно более высокого. Кстати. Показывать это ТЗ программистам совершенно необязательно.
2. Для программистов лучше писать на третьем уровне.

Об этом же, кстати, ГОСТ 34.

Об этом же, кстати, ГОСТ 34.

А вот это предлагаю внести в методические рекомендации по использованию ГОСТ от <придумайте от кого>:

Не рекомендуется включать ВИ в ТЗ по ГОСТ 34. ... и 19. ...

А вот это предлагаю внести в методические рекомендации по использованию ГОСТ от <придумайте от кого>:

Да вроде нет у нас таких. Была тема, в которой собирались сформировать ЧАВО, да так и не собрались, помнится.

Не рекомендуется включать ВИ в ТЗ по ГОСТ 34. ... и 19. ...

Совершенно верно. Неоднократно в разных темах обсуждалось.

Да вроде нет у нас таких. Была тема, в которой собирались сформировать ЧАВО, да так и не собрались, помнится.

Однако у меня все ходы записаны. Вопросы есть, ответов только нет.

Есть ли от нее польза. Да есть. С помощью нее можно демонстрировать студентам зависимость изменчивости требований от их уровня.  Предупредить их:
1. Если вы вынуждены использовать ТЗ как контракт, то постарайтесь не писать туда требования третьего уровня. Пишите второго уровня и как можно более высокого. Кстати. Показывать это ТЗ программистам совершенно необязательно.
2. Для программистов лучше писать на третьем уровне.

Добрый день. Слушала ваш доклад на аналитическом фестивале, и вот какой вопрос меня беспокоит. Вы настоятельно не рекомендуете писать требования третьего уровня в ТЗ. если оно идет приложением к Договору с Заказчиком. При этом почему вы не рассматриваете ТЗ как инструмент сдерживания "буйной фантазии" заказчика? Конечно, ТЗ не должно становится дубиной, при помощи которой за шаг влево или шаг в право расстрел. Должна быть возможность обсуждать требования, вносить изменения в соответствии с изменениями требований, но на взаимовыгодных условиях. Но всегда есть риск. что заказчику захочется большего, а формулировка второго уровня вполне позволяет это большее подогнать под требование.