Александр Запорожцев пишет:

Андрей Николаевич пишет: Допустим, вам удалось составить такую таблицу. Допустим её составляли сами стейкхолдеры. Нет, стейкхолдерам такая таблица не нужна. Такую таблицу будут составлять те участники проекта, которые будут работать с требованиями стейкхолдеров. такой специалист называется инженер по требованиям
Вы уверены в том, что они действительно думают то, что записали? Как ориентироваться на субъективное мнение? А зачем им что то скрывать? Все мнения субъективные - других мнений не бывает.
Как понять, что ВСЕ мнения ВСЕХ стейкхолдеров учтены? Есть такая шутка - стейкхолдеров всегда на одного больше, чем вы учитываете. Это задача инженера по требованиям .

В стандарте 42010 слово "требования" есть?

Эта будет еще одна конверсия. Сначала "цель" исказили при переводе "интереса". Потом конвертировали "интерес" в "требования". Еще одно искажение.

Александр Филонов пишет: В стандарте 42010 слово "требования" есть? Нет такого слова. Есть интерес, который должен быть учтен при разработке архитектуры системы. В реальной жизни это проходит через требования.

Эта будет еще одна конверсия. Сначала "цель" исказили при переводе "интереса". Потом конвертировали "интерес" в "требования". Еще одно искажение.

Мы же с Вами это вопрос подробно обсуждали

Александр Запорожцев пишет:

Александр Филонов пишет: В стандарте 42010 слово "требования" есть? Нет такого слова. Есть интерес, который должен быть учтен при разработке архитектуры системы. В реальной жизни это проходит через требования.

Эта будет еще одна конверсия. Сначала "цель" исказили при переводе "интереса". Потом конвертировали "интерес" в "требования". Еще одно искажение.

Мы же с Вами это вопрос подробно обсуждали

Мы с Вами обсуждали временную метаморфозу "цели" (view) -> в структурную (viewpoint), метод.
И обратную . Программный язык -> Программа.
Здесь.

Цепочка Цель -> Интерес -> Архитектура -> Архитектурное описание, и обратно, проходит через Систему, которую в "реальной жизни" Вы предлагаете называть "требования". Why?

Почему стандарт этого не требует, а Вы делаете?

Александр Филонов пишет: Мы с Вами обсуждали временную метаморфозу "цели" (view) -> в структурную (viewpoint), метод. view - это модель, входящая в описание архитектуры (основные элементы системы). viewpoint - это метод описание, соответствующий интересу стейекхолдера

Цепочка Цель -> Интерес -> Архитектура -> Архитектурное описание, и обратно, проходит через Систему, которую в "реальной жизни" Вы предлагаете называть "требования". Why?
Почему стандарт этого не требует, а Вы делаете?

Я ничего не требую - я рассказываю как в системной инженерии работают со стейкхолдерами. У стейкхолдера есть интерес к системе и он выражает свой интерес в виде требования. Все требования всех стейкхолддеров объединяются, согласовываются и по ним стариться архитектура системы.
В архитектуре для каждого стейкхолдера имеется viewpoint, в котором отражено представление интереса стейкхолдера в общей архитектуре

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

Александр Запорожцев пишет: ...первое - это опора на реальность, а не придуманное...

Что такое реальность? А что такое придуманное? Не факт, что придуманное не является реальностью... Мы оперируем только образами! Поэтому, оперировать надо мслеобразами имеющими практическое подтверждение и то, с осторожностью. Другими словами опираться надо на факты и события увиденные своими глазами. "ВСЕ В ГЕМБУ!!!"

Александр Запорожцев пишет: ...второе - нужно смотреть в перед только на один шаг, а не строить фантастические замки...

А как же стратегия? Одной тактикой не обойтись! Если вы идёте по болоту и видите, что есть хорошая тропинка, то не факт, что она приведёт вас к цели. И наоборот, пройдя некоторое время по шею в воде вы можете выбраться на асфальтированную дорогу ведущую туда, куда вам надо.

Александр Запорожцев пишет: третье - нужно постоянно искать лучшее продолжение, а не идти к намеченной цели.

Если следовать данному совету, то вы не сдвинетесь с места никогда! Нет предела совершенству.

Андрей Николаевич пишет:

Александр Запорожцев пишет: третье - нужно постоянно искать лучшее продолжение, а не идти к намеченной цели.

Если следовать данному совету, то вы не сдвинетесь с места никогда! Нет предела совершенству.

А Вы оглянитесь вокруг - природа все время меняется, хотя у нее нет никакой цели! Даже естественный разум могла создать!

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

Если первое и второе - просто лозунги, то третье вызывает недоумение. Разве лучшее имеет смысл без ответа на вопрос "по какому критерию?", а он, в свою очередь, "для чего лучшее именно по этому критерию", то есть, в конечном итоге, "для какой цели это лучшее?"
Я могу только предположить, что Левенчук имеет в виду, но у нас же не КВН. А что имеете в виду Вы?

Георгий Лейбович пишет: Если первое и второе - просто лозунги, то третье вызывает недоумение. А что имеете в виду Вы?

Вот как мы понимаем один из элементов Глубинных знаний Деминга - вариабельность?
Большинство из нас понимает только то, что все в реальности изменяется. Это уже прогресс - значит мы не будем наказывать за случившееся.
Талеб пошел значительно дальше - он рассматривает редкие явления и предлагает подходы как их учитывать.
Это требует кардинальной перестройке нашего мышления - без такой перестройки невозможно понять смысл сказанного Талебом.
Если я правильно понял Талеба, то хрупкость - это централизованное планирование, а антихрупкость - вытягивающая система.
Но это очевидные вещи, а вот что такое фундаментальная асимметрия, когда в данной ситуации кто-то больше приобретает, чем теряет, то это антихрупкость и выигрыш построен на переменчивости, случайности, ошибок, неопределенности, стрессоров и времени. А если ориентированться на стабильность, то это хрупкость. И это только одно понятие, а их в книге приведено 47!!!

Александр Запорожцев пишет: ...Талеб пошел значительно дальше - он рассматривает редкие явления и предлагает подходы как их учитывать...

А зачем их учитывать, если они редкие? Кстати, а что такое редкое явление? Кроме того, учитывается ли степень влияния этого явления на процесс?
То есть вы предлагаете разрабатывать мероприятия на случай землетрясения и падения метеоритов?