Об этом, думаю, рассказать в отдельной статье, но если кратко - не планарность означает дублирование вычисляемой связи, обычно это говорит о не полном или не корректном понимании аналитиком реальной связи между объектами. Нарушение планарности нужно при проектировании ДБ, например, а точнее для оптимизации нагрузки при проектировании ДБ.
Мой опыт говорит, что вот такой подход, желание описать все, соблюсти все правила UML и перфекционизм в рисовании диаграмм, вместо перфекционизма в передаче требований и приводит к скатыванию к попыткам замены разработки нормальных полноценных моделей требований на описание системных требований в виде нумерованных списков в документах типа BRD или в тикетах в Jira/Redmine/etc
Ваши заказчики не согласовывают ТЗ ни в каком виде? Если не секрет, как вы актируете работы в таком случае?
На самом деле не очень, хотя я тоже об этом думал когда рисовал :)
Системный анализ, в моем понимании, не включает в себя описание бизнес-процессов.
Об этом, думаю, рассказать в отдельной статье, но если кратко - не планарность означает дублирование вычисляемой связи, обычно это говорит о не полном или не корректном понимании аналитиком реальной связи между объектами. Нарушение планарности нужно при проектировании ДБ, например, а точнее для оптимизации нагрузки при проектировании ДБ.
Мой опыт говорит, что вот такой подход, желание описать все, соблюсти все правила UML и перфекционизм в рисовании диаграмм, вместо перфекционизма в передаче требований и приводит к скатыванию к попыткам замены разработки нормальных полноценных моделей требований на описание системных требований в виде нумерованных списков в документах типа BRD или в тикетах в Jira/Redmine/etc