Не, господа, я в шоке )

Вы тут второй год мусолите каждый своё, не отвечая на заданный вопрос.Так с чего же следует все-таки начинать? Какие "правильные" вопросы необходимо задавать работникам в этой предметной области? Есть ли стандарты на это?Во-первых, интересующая вас тема - не проектирование БД, а подготовка к проектированию БД, традиционно называемые как этапы Постановка бизнес-задачи, Бизнес-моделирование, Определение требований и только потом уже Системный анализ и проектирование, включая проектирование БД.

Постановку бизнес-задачи надо обсуждать с Заказчиком, или будущим Владельцем системы.

Вопросы, которые ему стоит задать, это:
1) почему вообще пошла речь о создании системы
2) в чём вы видите её назначение
3) какие бизнес-возможности она должна реализовать
4) какие проблемы должна решить.

В качестве "Стандарта" на вопросы такого рода смотрите шаблон документа "Stakeholder Request", например, из RUP (кто не найдёт - могу прислать). Бизнес-требования может выразить Заказчик или Эксперты предметной области. Они обычно фиксируются в виде списка из 10-30 ключевых свойств продукта - в качестве шаблона см. Vision из RUP.

Бизнес-моделирование надо проводить на основе информации от, а лучше совместно с экспертами предметной области. Вопросы по сути сводятся к "Что, почему, когда, как и кем происходит в предметной области и как оно взаимосвязано?":

1. Каковы основные понятия предметной области, их определения и взаимосвязи? Результат можно оформить в виде глоссария и/или концептуально-семантической модели предметной области.

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

3. Что реально (какие процессы, события, факты) происходит и в какой последовательности, взаимосвязи? Результат оформляете в виде сценариев описания бизнес-процессов (что достаточно универсально) или диаграмм SADT (IDEF0, IDEF3, DFD) / ARIS (eEPC и т.д.) / UML (Business Use-case Diagram (BUC) + Activity Diagram + Sequence Diagram). Это один из сложнейших этапов.

4. Какими свойствами обладает каждое из выделенных понятий - структурными и поведенческими? Результат описывается в виде таблиц с атрибутами Концептуальных сущностей или Детальной концептуальной моделью - ER - IDEF1X / UML Class Diagram (BOM).

Определение требований - частично Бизнес-требования и Требования, проистекающие из предметной области вы уже определили выше, теперь осталось исследовать Пользовательские требования и Системные требования и ограничения к отдельным аспектам качества системы. Пользовательские требования, как можно понять, нужно выявлять из общения с потенциальными пользователями системы. Вопросы:
1) На какую систему будет похожа создаваемая?
2) С какими системами и как давно вы работаете?
3) Какое у вас образование?
4) Каковы ваши ожидания от системы - что и как она должна делать, какие задачи помогать решать, как должна выглядеть?
5) Какие шаги необходимо предпринятть для решения каждой задачи?
6) В каком случае вы будете считать, что система "Хороша"?
Результаты анкетирования/интерьюирования обычно представляют в виде пользовательских историй (User Story, Agile) или Пользовательских сценариев (Use-case), также возможно их диаграммное представление средствами диаграмм потока работ (IDEF3), ARIS (?), Activity/State UML Diagram.

Системные требования нужно выяснять у IT-специалистов Заказчика, если таковые имеются, из специфики контекста использования системы, опыта построения аналогичных систем (у IT-Экспертов-Архитекторов) и Специалистов по отдельным аспектам системы, значимым для данного проекта (Юристы, Эргономисты, и т.д.) и Заказчика - будет ли система единичной или тиражируемой? В каких странах она будет работать? Насколько важна информация, хранящаяся, обрабатываемая и передающаяйся системой? Каков возможный ущерб от потери той или иной информации? Сколько пользователей будет работать с системой сегодня, завтра, через год? Переработанный результат оформляется в виде Системных требований (Software Requirement Specification, стандарт IEEE-STD-830-1998, или ТЗ ГОСТ 34-602-89 или неформально в виде Supplementary Specificaion из RUP).