Интересный вопрос!
Сначала думал, что ТЗ на входе, однако углубился в стандарт IDEF0 и понял, что ТЗ это управление.

Привожу текст из стандарта, который идет как руководство по созданию диаграмм в приложению к формальному описанию, где че:

-----------
Sketch interface arrows connecting to each individual box. Connect ends of arrows to show
which outputs supply which inputs and controls.

Recall that input data/objects are transformed by the function to produce the output. If an arrow
contains both input and control data/objects, show it as a control . If it is uncertain whether an
arrow is a control or an input, make it a control . If it is unclear whether or not a particular data
or object arrow is needed at all, leave it out (as long as it is not the only control).

Think control and constraint, not flow .

A basic rule for layout of the arrow structure is “constrain, don’t sequence.” That is, make the
diagram structure show relationships that must be true no matter which sequence is followed.

Even though something must progress from stage to stage to reach some desired end result, try to
express the constraints that must be satisfied or the invariant properties that must be true rather
than some one specific sequence of steps that will yield that result.
The reason is that all boxes may be active simultaneously. Thus, sequence has no meaning.
It is always more powerful to constrain than to sequence. Wherever possible, diagrams should
be created that say the right thing regardless of what steps are taken first. Clearly, this is better
than restricting to only one of the possible sequences.
------------

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

Это можно так объяснить: ТЗ есть требования к проекту, оно используется, но не преобразуется в процессе работы над ТП. Разработчики ТП создают его в соответствии с ТЗ и, есть есть, методикой проектирования, о которой упоминал один из авторов.

Кстати, а что тогда будет входными данными для ТП?