[quote="Александр Запорожцев"
Но есть successful systems![/quote]

И где?

Ссылку в словаре можете привести?

Александр Филонов пишет: [quote="Александр Запорожцев"
Но есть successful systems!

И где?

Ссылку в словаре можете привести?[/quote]
The definition of systems engineering has evolved over time. The current accepted definitions are found below:

(1) Interdisciplinary approach governing the total technical and managerial effort required to transform a set of customer needs, expectations, and constraints into a solution and to support that solution throughout its life. (ISO/IEC/IEEE 2010)

(2) An interdisciplinary approach and means to enable the realization of successful systems.

Это укороченное определение. Полное в словаре


Раздуть мимолетом сказанное successful из этого контекста - это еще надо уметь!

Если эту красочную, не имеющую определения ремарку убрать из текста, практически ничего не изменится.

Давно собирался спросить, да всё забывал. А как согласуются или отбираются требования стейкхолдеров в СП 2.0? Какие критерии отбора и согласования кроме абстрактного "удовлетворения" требований. Для ограниченного проекта? А для развития компании? Только не ссылайтесь на СД-картинку, там нет критериев принятия решения.

Георгий Лейбович пишет: Давно собирался спросить, да всё забывал. А как согласуются или отбираются требования стейкхолдеров в СП 2.0? Какие критерии отбора и согласования кроме абстрактного "удовлетворения" требований. Для ограниченного проекта? А для развития компании? Только не ссылайтесь на СД-картинку, там нет критериев принятия решения.

Требования не выбираются, а выявляются. Сначала выявляются сами стейкхолдеры, а потом выявляются их требования, причем процесс выявления требований идет на всем протяжении проекта. принято моделировать требования с использованием диаграммы use case языка моделирования UML. Далее идет этап согласования требований с тем, чтобы добиться общего понимания архитектуры системы.
В теме требований для меня очень много непонятного - пытаюсь разобраться.

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

Георгий Лейбович пишет: Давно собирался спросить, да всё забывал. А как согласуются или отбираются требования стейкхолдеров в СП 2.0? Какие критерии отбора и согласования кроме абстрактного "удовлетворения" требований. Для ограниченного проекта? А для развития компании? Только не ссылайтесь на СД-картинку, там нет критериев принятия решения.

Требования не выбираются, а выявляются. Сначала выявляются сами стейкхолдеры, а потом выявляются их требования, причем процесс выявления требований идет на всем протяжении проекта. принято моделировать требования с использованием диаграммы use case языка моделирования UML. Далее идет этап согласования требований с тем, чтобы добиться общего понимания архитектуры системы.
В теме требований для меня очень много непонятного - пытаюсь разобраться.

Полагаю, ВЫ не поняли вопрос или не готовы к нему. Можно выявлять, но потом возникает проблема согласования. Что является основой для согласования, какие критерии? Мир-дружба или что-то более осмысленное, измеримое?

Георгий Лейбович пишет: Полагаю, ВЫ не поняли вопрос или не готовы к нему. Можно выявлять, но потом возникает проблема согласования. Что является основой для согласования, какие критерии? Мир-дружба или что-то более осмысленное, измеримое?

По большому счету к ответу на вопрос не готов. Это отдельная дисциплина "Инженерия требований" там много чего есть. Согласование требований - это частный вопрос и, на сколько я понял, не самый главный. Одна из проблем формулируется так - "есть еще стейкхолдеры, требования которых мы не учли". Другая проблема - требование было, но его потеряли и не учли.

Александр Запорожцев пишет: По большому счету к ответу на вопрос не готов. Это отдельная дисциплина "Инженерия требований" там много чего есть. Согласование требований - это частный вопрос и, на сколько я понял, не самый главный. (- выд. ГЛ) Одна из проблем формулируется так - "есть еще стейкхолдеры, требования которых мы не учли". Другая проблема - требование было, но его потеряли и не учли.

Мне странно это читать. С моей точки зрения, вопрос о том, как согласовывать требования стейкхолдеров - центральный вопрос. Бессмысленно собирать, выявлять и не терять требования, если нет чёткой методологии того, как с ними поступать. И что означает "согласование" для команды проекта или руководства компании. Чьи интересы доминирующие и по какому (каким) критерию? Есть ли матобеспечение?
Я понял, что Вы пока не знакомы с ответами на эти вопросы, но не относитесь к ним, как к частным. Это базовый вопрос. Без ответа на них вся остальная деятельность не имеет смысла.

Георгий Лейбович пишет: С моей точки зрения, вопрос о том, как согласовывать требования стейкхолдеров - центральный вопрос. Бессмысленно собирать, выявлять и не терять требования, если нет чёткой методологии того, как с ними поступать.

В стандарте isi 15288 Процессы жизненного цикла в разделе Технические процессы установлено два процесса работы с требованиями :Процесс определения требований заинтересованных сторон,
Процесс анализа требований и Проектирование архитектуры
В Процессе определения требований заинтересованных сторон проект, согласуясь с соответствующей политикой и процедурами организации, должен осуществить
следующие виды деятельности.
a) Идентифицировать отдельные заинтересованные стороны или классы заинтересованных сторон, которые имеют правомерный интерес к системе в ходе всего жизненного цикла.
b) Выявить требования заинтересованных сторон.
c) Определить ограничения на системное решение, которые являются неизбежными последствиями существующих соглашений, управленческих и технических решений.
d) Определить характерный набор последовательностей видов деятельности, чтобы идентифицировать все требуемые услуги, которые соответствуют ожидаемым эксплуатационным и поддерживающим сценариям и средам.
e) Определить взаимодействие между пользователями и системой.
f) Определить требования, связанные с безвредностью для здоровья, безопасностью, защитой, средой и другие требования заинтересованных сторон, а также функции, которые касаются критичных качеств.
g) Проанализировать полный набор выявленных требований.
П р и м е ч а н и е — Анализ включает в себя выявление и расположение по
приоритетам конфликтующих, недостающих, неполных, неоднозначных, противоречивых,
неуместных или непроверяемых требований.
h) Решить проблемы, связанные с требованиями.
П р и м е ч а н и е — Это включает в себя требования, которые не могут быть реализованы, или достижение которых нецелесообразно.
i) Возвратить проанализированные требования соответствующим заинтересованным сторонам, чтобы гарантировать, что потребности и ожидания были адекватно зафиксированы и выражены.
П р и м е ч а н и е — Объясните и получите соглашение на предложения о том, как разрешить конфликтующие, непрактичные и нереализуемые требования заинтересованной стороны.
j) Совместно с заинтересованными сторонами установить, что их требования выражены правильно.
П р и м е ч а н и е — Это включает в себя подтверждение того, что требования заинтересованных сторон являются понятными для создателей, и что разрешение конфликта
в требованиях не разрушило или не поставило под угрозу намерения заинтересованных сторон.
k) Записать требования заинтересованных сторон в форме, подходящей для управления требованиями в ходе жизненного цикла и по его завершении.
Возможно, выделенные цветом пункты, соответствуют вашему вопросу о том, как рекомендуется работать с требованиями

Функциональный подход ставит своей целью максимальное использование компетенций всех участников инженерного проекта. Считается, что основой построения целевой системы являются требования стейкхолдеров (внешних и внутренних). Однако, очевидно, что все стейкхолдеры имеют разный уровень компетенций в области проектирования систем. Ошибкой является решение возложить ответственность за принимаемые решения только на системного архитектора. Другой крайностью будут решение уравнять системного архитектора в принятии проектных решений с остальными стейкхолдерами. Более разумным представляется использовать компетенции каждого стейкхолддера с максимальной пользой для системного проекта. С этой целью собираются и анализируются требования всех стейкхолдеров, а системный архитектор разрабатывает модель существующего состояния системы «как есть». Такая модель позволяет лучше понять требования стейкхолдеров, выявить движущие силы требований стейкхолдеров, что может существенно продвинуться в направлении построения обобщенной системы «как должно быть».

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