Без заголовка

Когда мы меняем природу "требования", меняем природу "трассировки", переходим на управление конфигурацией в контексте всего жизненного цикла, а базис требований становится всего лишь частью общей информации модели, а не отдельной "базой данных требований", мы должны ожидать, что меняются и все остальные практики, связанные с требованиями. Так, сбор требований сразу может проходить в форме моделей, без предварительного текстового описания в виде полотен бумаги. Анализ требований -- тоже связан с моделированием. Хуже того, если рассматривать исполнимые спецификации, то спецификация часто может являться реализацией, по крайней мере, прототипом. Особенно, это касается библиотечных спецификаций. К примеру, рассмотрим (софтверное) требование, что функция должна выдавать в качестве результата масимальный элемент из списка переданного в параметре. Пример конечно примитивнй, но тем не менее, если записать требование в виде forall params, In (func params) params /\ forall a, In a params -> (func params) >= a, то нетрудно представить себе алгоритм, который такие спеки при некоторых условиях преобразует в исполнимый код (логическое программирование, программирование в ограничениях).