Т.е. на выходе и входе верхнего уровня такой модели необходимо вводить сущность "запись в формуляре". Не получится большое количество таких сущностей на входе-выходе?

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

Хорошая тема. Но возвращаясь к вопросу о правилах и проверках при рецензировании модели.
Имеем следующее:
Методология IDEF0 незначительно отличается от классической схемы описания бизнес-процессов DFD, которая была рассмотрена ранее. Основным отличием является наличие в языке дополнительной аналитики. Данный стандарт описания бизнес-процессов предлагает показывать не просто входы и выходы, как это делается в DFD – формате, он предлагает ввести три типа входов. Первый тип входов назвали так же входом, а два других входа назвали управлением и механизмами.
В стандарте IDEF0 c помощью входа показывают объекты – информационные и материальные потоки, которые преобразуются в бизнес-процессе. С помощью управления показывают объекты – материальные и информационные потоки, которые не преобразуются в процессе, но нужны для его выполнения. С помощью механизмов стали показывать механизмы, при помощи которых бизнес-процесс реализуется: технические средства, люди, информационные системы и т.д.

Теперь сами правила, точнее больше напоминания:
1.   В пояснительном тексте к контекстной диаграмме должна быть указана цель построения диаграммы и зафиксирована точка зрения. Точка зрения определяет уровень детализации, направление развития модели и позволяет разгрузить модель. Так при моделировании можно отказаться от детализации и исследования отдельных элементов, не являющихся необходимыми, исходя из выбранной точки зрения на систему.
2.   Функциональный блок (или Функция) преобразует Входы в Выходы (т.е. входную информацию в выходную), Управление определяет, когда и как это преобразование может или должно произойти Исполнители непосредственно осуществляют это преобразование.
3.   Заранее определиться с терминологией.

Что еще?

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

Рекомендации и правила выбора точки зрения и цели моделирования? Очевидно, что цель моделирования определяет точку зрения. Цель определяет и список вопросов, на которые следует ответить модели. Тогда точка зрения -  та, которая отвечает на большинство поставленных вопросов.
Однако чаще всего цель и точка зрения выбирается очень произвольно (студентами имеется в виду)

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

А материальные потоки? а кто такие исполнители? Вы имели в виду механизмы? но механизмы - это не всегда исполнители.

Что еще?

1. каковы правила отнесения входа в управление, вход или механизм
2. если вход покрывает несколько типов, как быть?
3. может ли порождаться выход - если нет явных входов (для материальных потоков)
4. может ли быть материалный вход, но отсутствовать материальный выход?
5. каковы правила декомпозиции, как определять что блоки на одном уровне рассмотрения?
6. как правильно именовать блоки, стрелки
7. что отличает хорошую модель, от плохой

Цель и точка зрения - это все-таки мне как мне видится должно быть в задании студенту.
Т.е. рассмотрите (нарисуйте) модель с точки зрения того-то.

Получается как бы небольшое описание к модели.

Исполнители  - это имелось ввиду механизмы.

В целом по вопросам проверки мне видится что в каждом случае надо разбираться.
Но при этом можно использовать созданные методики. Во вложении (tk_ pb.rar - просто к сведению).

По поводу вопросов "каковы правила отнесения входа в управление, вход или механизм" здесь больше вопросов чем ответов.  
И здесь

Однозначного понимания того, на вход или на механизм поступают фин.ресурсы после прочтения многочисленной литературы по ИДЕФ-ноль у меня не сформировалось. Увиденые модели БП допускают и тот и другой вариант.

и на нашем форуме пока четкого ответа нет.
Есть рекомендации   IDEF0 и опыт разработки в которых сказано

Для практического удобства может быть предложена иная (зауженная) интерпретация исходных примитивов стандарта IDEF0 (см. Рис.1 “Общая модель БП (В)”). Основная идея предлагаемой рекомендации по конкретизации языков моделирования БП состоят в следующем:

(1)   Все “Работы” принадлежат одному классу, т.е. обладают одинаковым набором свойств и поведением. Этот важный и часто нарушаемый принцип отдельно обсудим ниже.

(2)   Все связи между “Работами” относятся к классу “Ресурс”. Например, электронное издание “Налогового кодекса РФ” является общедоступным информационным ресурсом.

(3)   Для однозначной “привязки” ресурсов к трем возможным входам БП на множестве “Ресурсов” вводится следующая классификация.

1.   Признак изменчивости “Ресурса” при исполнении “Работы”.

1.1.   “Ресурсы”, подлежащие трансформации в другие виды “Ресурсов”.

1.2.   Нетрансформируемые “Ресурсы”.

1.2.1.   Неизнашиваемые “Ресурсы”. Например, большая часть информационных “Ресурсов” в электронной форме являются неизнашиваемыми.

1.2.2.   Изнашиваемые (устаревающие) “Ресурсы”. Например, вспомогательные инструменты, персонал.

2.   Признак блокировки “Ресурса” “Работой”, исключающий возможность использования “Ресурса” другими “Работами”

2.1.   “Ресурсы”, которые не могут блокироваться “Работами” (“Ресурсы” общего пользования)

2.2.   Блокируемые “Ресурсы”

Возможно и к данной классификации есть вопросы (точнее они  есть в данной статье ) но все же это может помочь

Ищите по ссылкам:
http://mmpk.appach.ru/ и http://www.fondgp.ru/
Материалов там море, и сходу то, что нужно я найти не могу.
Еще поищите книгу Анисимова "Основы методологии"

Ищите по ссылкам:
http://mmpk.appach.ru/ и http://www.fondgp.ru/
Материалов там море, и сходу то, что нужно я найти не могу.
Еще поищите книгу Анисимова "Основы методологии"

Спасибо за ссылки, это весьма познавательно, но мое мнение, твои рекомендации слишком абстрактны в свете обсуждаемого вопроса.

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

Да, Вы правы, уважаемый Thyestes. Вы привели интересную подборку публикаций и обсуждений. Увеличение возможностей ведет и не к однозначности использования и восприятия. Главное отличие IDEF0 именно в разделение семантики входов создает и чуть ли не основную трудность в корректном применении. Однако может не стоит искать в этом нечто сакральное?

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

Однако, делая различие между входными дугами и дугами управления, SADT дает аналитику возможность точно описать ограничения, накладываемые на функции преобразования. Ограничения позволяют получить более верное представление о работе системы, поскольку они описывают факты и правила, которым должны следовать функции преобразований.
[5.4. Различие между входными дугами и дугами управления. Методология структурного анализа и проектирования SADT]

В SADT система описывается в первую очередь с точки зрения ее функций. Но система должна быть в конечном итоге реализована (т.е. быть работоспособной), поэтому дуги механизма SADT имеют большое значение при описании системы. Они дают аналитику возможность точно определить способ выполнения конкретной функции, какие ресурсы требуются для этой функции, кто будет выполнять ее и т.д. С помощью дуг механизма аналитик может добавить к описанию последние детали, не вызывающие сомнений в том, что происходит при выполнении функции.
[5.5. Дуги механизмов определяют способы реализации функций. Методология структурного анализа и проектирования SADT]

Т.е. читатель(рецензент) обращает внимание на акценты автора, и может усомниться в их корректности, либо согласиться с ними?

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