Вся системная инженерия -- про то, как сделать систему из ее частей так, чтобы она была системой, а не суммой частей. Стандарт ISO 15288 по большей части не придерживается системного подхода: основная процедура там "разноска" (например, требований по частям системы -- allocation), причем с обеспечением "трассировки" (http://en.wikipedia.org/wiki/Traceability_matrix). Среди всех недостатков данного стандарта этот -- главный.
Беда в том, что с настоящими системами никакие "разноски" и "трассировки" не работают: свойства системы (системные свойства) не отнесешь/разнесешь к ее частям, а не разнесешь -- поэтому и не оттрассируешь. Так, качество является системным свойством. Характеристики качества потому и оказываются неуловимы, что они системны и не могут быть сведены к характеристикам частей системы -- они не могут быть "разнесены" и эта разноска не может быть "оттрассирована". Каждая деталь пиджачка может быть качественна как автономная система, но пиджачок в целом, составленный из этих подсистем, вполне может "не сидеть". Про качество пишут философские романы (http://www.pirsig.narod.ru/). Качеством спекулируют под именем ISO 9000. Качество системно, поэтому оно трудно дается.
Donald Firesmith (http://en.wikipedia.org/wiki/Donald_Firesmith) четко определяет характеристики качества, как относящиеся к нефункциональным характеристикам (наряду с характеристиками интерфейсов и данных). Это такие характеристики, как "ности" (в английском -- "ilities": reliability, mainteinability и т.д., включая safety и security) надежность, ремонтопригодность и т.д., включая безопасность и защищенность. Если мы требуем, чтобы у системы такие характеристики присутствовали -- это и есть требования качества, часть нефункциональных требований.
Поскольку эти требования эмерджентны и практически нетрассируемы к отдельным структурным элементам системы, то традиционный способ "разделяй и властвуй" с ними не работает. Так, для обоснований наличия нужной степени ностей применяется особая форма -- "оценочное дело" (в данном случае -- "дело о качестве", quality case). Качество не доказывается логически, качество доказывается как в суде: через поддержку заявлений о его наличии аргументами, и поддержку аргументов какими-то свидетельствами. Логика присутствует, но она тут теоретически бессильна: из того, что все составляющие бинарного газа безопасны вовсе не значит, что сам бинарный газ как система будет безопасен.
Абсолютно аналогично обстоит дело в архитектурном синтезе. Есть функции системы, и функциональные структуры. Нужно сообразить, как конструкция системы обеспечит функции. Конструкция не трассируется напрямую к функциям, но определяет их. "Функциональные системы" -- это не системы, их границы произвольны. Функциональный анализ ничего не скажет, что нужно сделать (что реализовать: построить, соорудить, закодировать), чтобы система могла выполнить все эти наанализированные функции. Нужно сделать архитектурный синтез, чтобы получить конструкцию -- получить описание системы на языке, понятном ее изготовителям (сборщикам, наладчикам). И тут же убедиться в том, что оттрассировать функции к элементам конструкции нельзя (я писал полтора года назад, разбираясь с работами системного инженера Jan Dietz по архитектуре: http://ailev.livejournal.com/600247.html).
От бухгалтера требуют предъявить баланс дебита и кредита, но не требуют предъявить трассу от каждого прихода к каждому расходу -- хотя как этого всем хочется! Именно от этого возникает дурилово с "себестоимостью" и той самой "разноской", от которого открещивается Голдрат (учет прохода http://webfile.ru/3994425 и дальше учет ограничений http://ailev.livejournal.com/467813.html). Именно поэтому Голдратт относит себя к последователям системного подхода, что понимает про нетрассируемость системного прохода к частям обеспечивающей его системы.
Итого: системный подход вы начинаете реализовывать на практике там и тогда, где и когда вам нужно справиться с принципиальной, теоретической неразносимостью и нетрассируемостью. А если вы что-то системное "разносите" по частям системы, да еще и гордо "трассируете", это точно не системный подход.
Дисклеймер: сказанное вовсе не означает, что разносить и трассировать всегда вредно. Нет, конечно. Это делать полезно и нужно -- но при этом четко понимать, что при этом вы не занимаетесь разноской системных характеристик (например, требований качества) по частям системы. Конечно, вам придется как-то соотносить части с этими характеристиками, но для этого нужна не "разноска", а другие приемы -- в нахождении этих приемов и состоит искусство работать в системном подходе.