-- стейкхолдера, устанавливающего требования
-- стейкхолдера, проверяющего выполнение требований
и прописывает все это в рамочном законодательстве о техническом регулировании. А потом в технических регламентах пытается описать, какие требования эти потенциально страдающие третьи лица могли бы установить для тех или иных типов проектов.
Общепринято, что такие требования должны быть сформулированы не как принуждение использовать технологии (например, "использовать дисковые тормоза, если делаете грузовики"), а в виде конечного результата ("ваше двигательное средство, если может достичь 90 км/час, должно иметь тормозной путь по сухому асфальту не более 50м -- и ваши проблемы, какого сорта тормозные системы вы будете использовать. Хоть лаптем. Но мы придем, и проверим тормозной путь на данной скорости") -- performance base. Тут, конечно, есть уже некоторая подмена: маленький тормозной путь -- вовсе не удовлетворение требования стейхолдера "чтобы все остались живы, ежели чего". Это, конечно, паллиатив. Для других транспортных средств (катеров, самолетов, ракет) может просто не найтись условий измерения "на сухом асфальте", или может выясниться, что крейсерской скорости 90км/час не бывает (а бывает 900км/час), не бывает "тормозного пути" (как, например, для самолетов в воздухе). То есть полного ухода от конкретной технологии в формулировках не удается добиться.
Проблема с измерениями возникает в том числе по той причине, что требования dependability -- надежности, безопасности safety и security, и прочих вопросов доверия к системе (http://www.cs.st-andrews.ac.uk/~ifs/Teaching/MScSysEng-2004/Presentations/DependabilityReq.pdf) можно сформулировать в терминах низкой вероятности нежелательных событий, но нельзя непосредственно измерить эту низкую вероятность (нельзя, скажем, построить миллион атомных станций, подождать тысячу лет, а затем вычислить среднюю вероятность взрыва одной станции на основании испытаний).
Ежели государство с его регулированием в пользу третьих лиц оставить в стороне, то частные лица практически договорились о том, как поступать с требованиями dependability, когда они записаны в ТЗ и нужно продемонстрировать их выполнение (оттрассировать требования к принятым конструкционным и производственным решениям). После доброго десятка разных неудачных способов это сделать остановились на работающем варианте: assurance case (закрепляемый ISO 15026, http://ailev.livejournal.com/578461.html).
У регулятора тем самым остается два варианта, оба из которых страшно коррупционны:
1. Предположить, что технический прогресс остановился, закрепить использование какой-то технологии и определить объективно измеримые к ней требования (чем обязательно воспользуются все те, кто не хотел бы видеть на рынке никаких других технологий -- и они купят закрепление нужной технологии и нужные к ней требования).
2. Сформулировать требования безопасности в терминах вероятностей ущерба для жизни и здоровья, и потребовать предоставления assurance case (чем обязательно воспользуются все, чей assurance case не выдерживает никакой критики, или наоборот, конкуренты тех, у кого assurance case будет вполне нормальным, но после некоторой мзды от конкурентов в пользу технадзора вдруг неожиданно не пройдет).
Я лично склоняюсь ко второму варианту: в нем потенциально свободы больше, ибо в первом варианте закрывается свобода выбора технологических решений в вопросах безопасности, а вероятность покупки конкретного решения все равно остается. Также второй вариант интереснее и в том, что одна и та же технология assurance case используется для доказательств выполненности требований как частных стейкхолдеров, так и государства (не требуется поддержка разных технологий доказательства, можно использовать один и тот же софт, одних и тех же специалистов, одни и те же алгоритмы расчета).
Но по факту может оказаться, что правила формулирования assurance case (оформленные, например, в виде технических регламентов) будут столь же детальными, как корпус законов, прилагающихся в странах статутного права к разбирательству в судах по существу дела. И хрен окажется совсем не слаже редьки -- и покупать конкретные решения будут, и обставлять абстрактные правила assurance case конкретными технологическими требованиями в зависимости от подразумеваемых технических решений.
Есть еще одно (третье) мнение: оставить все как есть, ибо что ни делай -- будет только хуже по сравнению с сегодняшней ситуацией (которая в свою очередь, совсем ужасна, но ведь можно ухудшить и этот ужас!).
А вы как думаете?