Как-то так.

Я правда многого не понимаю.

Что такое «Оформить анкетирование персонала», например?

Я знаю, что есть подготовка анкетирования, проведение анкетирования, обработка результатов анкетирования, подготовка предложений по результатам анкетирования. Что именно у вас под «оформить»?

У меня должно быть все это сразу. Может "Провести работы по анектированию"?

Подниму тему, время идет платформа развивается, решения на 1С становятся все более глобальными а какой то культуры проектирования как не было так и нет.

К концу темы ушли от проектирования системы к описанию UC, в общем то у наших бизнес аналитиков нет проблем с описанием бизнеса, в основном используется ARIS. Получая от бизнес аналитиков схемы в общем то я ими доволен, и они помогают в работе (я ведущий разработчик).

Мои первоочередные задачи при проектировании системы, определить физическую модель данных:
1. Структуру хранения данных (Таблицы, состав полей).
2. Связи между таблицами.

Само по себе проектирование структуры хранения можно сделать и в конфигураторе, проблема в том что когда объектов конфигурации становится больше 30 - 40 да еще и большую часть создают другие люди то ориентироваться в конфигурации становится сложно, при этом средства по визуализации связей между объектами метаданных в 1С отсутствуют.

Т.е. для меня первоочередная задача это представление структуры БД.

Это в общем то несложная задача, в том же Visio можно создать Типы Справочник, РегистрСведений (хотя не совсем понятно как делать для этого типа виртуальную таблицу СрезПоследних), примерно так и происходит, но проблема в том что все это очень не удобно и времени на рисование схемы тратится очень много, плюс опять же опыта работы с UML нет, в книгах и курсах огромный объем информации причем я выделяю 2 типа:
1. Теория - сложно для понимания нужна для углубленного изучения когда уже есть понимание в принципе и требуется более детальное погружение.
2. Практические подходы с примерами - для быстрого изучения с последующим переходом к п1.

Книги обоих типов не сильно помогают в случае 1С т.к. в первом случае просто огромный поток информации который слабо пересекается с имеющимся опытом, во втором случае все очень сильно оторвано от особенностей платформы 1С.

т.е. для формирования культуры проектирования нужен человек у которого за плечами 3-4 года работы с UML и который хотя бы 2 года работал с 1С наверное только в этом случае получится применить UML для 1С.

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

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

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

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

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

Если вопрос только в модели данных и ответить кратко, то в UML имеет смысл фиксировать только бизнес-объекты и их связи (это может делать аналитик). Для более детального проектирования данных для 1С UML непригоден.