Рекомендуется следующая последовательность при построении функциональной модели [6]:

(1) формирование цели моделирования;

(2) выбор точки зрения;

(3) определение области моделирования;

(4) создание блока контекстной диаграммы;

(5) создание стрелок на контекстной диаграмме;

(6) создание диаграмм декомпозиции;

(7) создание диаграмм узлов и иллюстраций.

Цель моделирования. Модель не должна создаваться без ясного осознания цели моделирования. При выборе цели следует ответить на такие вопросы: почему моделируется данный процесс? что выявит данная модель? как ее смогут применять? Вот пример цели моделирования: выявить задачи каждого сотрудника компании для разработки руководства по обучению новых сотрудников.

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

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

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

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

Стрелки проще проектировать в таком порядке: (1) выход, (2) вход, (3) механизм, (4) управление.

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

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

Определение входов. Входы можно рассматривать как особым образом преобразуемые блоками сырье или информацию для получения выходов.

Определение механизмов. После создания входов и выходов можно приступать к рассмотрению механизмов исполнения или ресурсов, относящихся к блоку.

Определение управления. Наконец, должно быть определено управление, контролирующее ход работы блока. Все блоки должны иметь хотя бы одну стрелку управления.

После завершения работы над контекстной диаграммой следует задать следующие вопросы. Обобщает ли диаграмма моделируемый бизнес-процесс? Согласуется ли диаграмма с областью, точкой зрения и целью моделирования? Подходит ли выбранный уровень детализации стрелок для контекстного блока?

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

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

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

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