В 98% проектов мэйнстрима работа строится на реализации весьма неформальных требований, которые выдвигает заказчик, по относительно простому механизму. Заказчик рассказывает свои хотелки исключительно неайтишными терминами (только в рамках своей предметной области), аналитик более-менее это всё формализует и переводит в техзадание, которое затем тимлид декомпозирует и распределяет по тикетам между исполнителями в команде (это в идеале).

Однако если вы пообщаетесь на эту тему со взрослыми системными инженерами, они заговорят с вами прежде всего на тему "онтологии". Так в чём разница между "требованиями" и "онтологией"?

Ну, вот вам например важный лайфхак: "требования заказчика" всегда представляйте как "фантастические представления заказчика о требованиях" )))

Например, такое понятие как "женитьба" системный инженер может описать как "документация факта заключения брачного договора по форме N123бис между двумя особями противоположного пола", однако вполне может оказаться, что заказчик подразумевал требование "возможность получить скидку 50% на свадебный торт".

Как правильно думать над проектом и в парадигме "требований", и в парадигме "онтологии" (с привлечением Хайдеггера, который здорово рассуждал о моделировании мира) применительно к вашей повседневной практике, скоро разберу для курсантов в СильныхИдеях, дам несложную думательную машинку соответствующих рассуждений.

Оба подхода имеют общую цель: найти достаточно выразительную модель данных, которая чётко выражает то, что необходимо системе для выполнения своей работы. Совместим сильные стороны и рассмотрим, чему стоит поучиться у каждой из них.