Обсуждение

4 как-то внезапно влезло. Всё-таки «инженер по требованиям» и «архитектор» — это разновидности системных инженеров? Странно, что в связке с моделью целей не прозвучал термин «образ будущего». Также интересно, что вам удалось обойтись без вездесущего термина «проблема». В данной ролевой модели осталось неясным, кто производит анализ требований на соответствие правилам, анализ зависимостей требований и поиск и разрешение конфликтов в том случае, если их сотни.

***Так, знакомые с игротехникой люди начинают нервно реагировать на любые похожие на игротехнику приемы работы -- см., например, .*** ???????????

Осталось за скобками, как работа инженера требований связана с изучением предметной области как системы понятий и изучением устройства организации деятельности, которую должна поддержать или преобразовать создаваемая система. А именно эти модели служат основанием для анализа полноты и согласованности системы требований — а следовательно, её качества и полезности для достижения заявленных целей.

Да, инженер по требованиям и архитектор -- разновидности системных инженеров (как стоматолог и гинеколог разновидности врачей, это пример Donald Firesmith сотоварищи в книжке про инженерию системной архитектуры MFESA). Мое мнение при этом чуток другое ("системный инженер -- это то общее, что объединяет всех инженеров" и в этом смысле "врач -- это то общее, что знают стоматолог и гинеколог"), но я пока не слишком спорю с общепризнанными определениями. В INCOSE признают, что в этой сфере (что такое системная инженерия и кто такие системные инженеры) существенное разнообразие мнений. Образа будущего нет, я опираюсь на онтологию, выразимую в указанных языках инженерии целей (OMG BMM, карты действий и результатов Голдратта, URN=GRL+UCM, i* и т.д.). У меня самого тут цель выйти на удовлетворяющий меня язык описания целей. А "образ будущего" -- это другой тип артефакта, и искать его нужно в архитектурных артефактах. В этом тексте не написано, но раньше я неоднократно повторял (и в видео растолковывал подробно), что "требование" -- это просто фрагмент [архитектурной] модели системы, с добавленным деонтическим оператором (степень долженствования) и возможным указанием на полномочность того, кто добавил этот оператор. Так что "полномочность добавления деонтики к архитектуре" у инженера по требованиям, а само "содержание требований" -- это епархия архитектора. Тут особо отмечу, что "требования" и "цели" вещи немного разные, и анализ того, что из "требований заинтересованных сторон" относится к "интересам" или "целям", а что является именно требованиями к конкретной системе тут я просто не привел. И так большой текст получился.

Это архитектура: модель операционного окружения (эксплуатирующей среды) системы со вписанной в нее моделью системы (как раз помянутые в конце холоны: матрешка систем). Другое дело, что инженер по требованиям интересуется социальной составляющей -- для него важны позиционеры в операционном окружении, и взаимоотношения между этими позиционерами. Устройство организации деятельности, конечно, инженер требований должен знать (кстати, в языки целей входят и tasks -- действия, которые нужно предпринимать, чтобы удовлетворять целям. Эти tasks описываются на чем-то типа упрощенных BPMN. Так что там с организацией все в порядке). Заодно знание "организации инженерного процесса" как таковой входит в общеинженерное умение, я об этом указал в самом начале текста. То есть общее знание про "организацию" в процессном заходе (ситуационная инженерия методов, являющаяся общей базой для ситуационной инженерии методов жизненного цикла, включая процессы использования системы) предусмотрено. Насчет полноты и согласованности системы требований: модель системы в системе ее окружения с оператором "должно быть так" и есть "система требований". У меня другая парадигма, у меня моделеориентированная системная инженерия, а не традиционная (со списком требований как набором деклараций о системе и развернутой моделью, удовлетворяющей этим декларациям: "набор требований Б--И--Р-А, сделайте модель системы! Модель системы: БЕЛИБЕРДА!". Для меня просто это модели системы разной степени подробности, сразу делаются в моделере. Стейкхолдерам предъявляются не тексты, а модели -- сразу, а не потом. Желательно модели делать в их присутствии, с их участием.

Не смог сходу найти ссылку на мой мемуар про одно из первых моих мероприятий: нашу команду вдруг записали в игротехники и объявили, что "будут сопротивляться". Проблема вдруг решилась, когда "игротехники клиента" заметили, как наш стажер делает гимнастику для рук (он тогда был барабанщиком), и только после этого перестали "сопротивляться" -- сочли нас "не игротехниками", а "колдунами". Когда-нибудь найду сссылку, а пока пусть так будет.

В зале сдержанные аплодисменты. Огромное спасибо.

К сожалению, в жизни при исполнении больших программ никогда не бывает исхоного пакета сформулированных требований, который остается неизменным до конца программы, как бы этого не хотелось. В ходе реализации вылезают технические, временные, экономические ограничения, что приводит к пересмотру требований на основе компромиссов. Это не означает несоответствие продукта ТЗ, а всего лишь скорректированное восприятие первоначального замысла (что нам мешает сегодня быть умнее, чем вчера). Поэтому требования "замораживают" уже в конце работы.Вопрос: стоит ли так мучиться в начале с требованиями, или сразу понимать, что детализация замысла приведет к последующему изменению конфигурации?

Системная инженерия требует как раз а) активно мучиться с требованиями с самого начала, а не под конец проекта. Это основной посыл: сдвиг главнейших решений ближе к началу проекта. б) продолжать мучиться с требованиями до самого конца, не замораживая их навечно в начале (т.е. пересмотров-заморозок проходит несколько в ходе проекта). Так что ответ на ваш вопрос не "или", а "и". Обращу также внимание, что по факту "требованиями" тут является непрерывно развивающаяся модель (а с учетом "развилок" -- набор моделей), с приписанными к ним статусами долженствования (деонтическими операторами) и трассировкой к заинтересованным сторонам и их интересам. То есть "требования" и "архитектура/проект" не существуют отдельно. Развивается (уточняется) архитектура -- развиваются (уточняются) требования, хотя многие высокоуровневые принципы/элементы архитектурной модели при этом сохраняются, и тем самым сохраняются высокоуровневые требования.

во всех обличьях узнаю то, чем я занимаюсь.... но интуитивно чувствую, что что-то еще не досказано - что-то еще должно быть это только ощущение - но по опыту оно скоро формализуется

"Если живой человек в такую позицию не упихивается (например, "вор" по внутреннему ощущению не будет упихиваться в позицию "представитель инвестора" -- его решения по проекту будут приводить к уменьшению прибыли "инвестора", но зато к обогащению его самого), или живых людей слишком много, и нет возможности сделать, чтобы они договорились (например, много-много департаментов крупной организации, каждый из которых себя и считает истинным представителем организации-позиционера), или живой человек недоступен по каким-то иным причинам, психотехник рекомендует сразу перейти к социотехнике (и тогда говорят про "метод персонажа")." Вот тут не совсем понятно, насколько я понимаю перейдя к социотехнике мы сможем сформулировать требования, но проблема того что живые люди не упихались в позиции с точки зрения которых были сформированы требования останется, и ее по любому придется решать. Наверное инженеру по требованию нужно будет как минимум как то зафиксировать возникшую проблему?

Конечно, что-то недосказано! Причем довольно много: у меня по плану на эту тему штук шесть постингов больших... :)

Зафиксировать проблему маловато будет, нужно будет ее решить. Хинт в том, что представители заинтересованных сторон не одиноки, а регулярно встречаются вместе. При этом существует два варианта: а) им публично при других стейкхолдерах предъявляется "культурная переговорная позиция" в явном виде (т.е. логика решения их "персонажа") и разница между их предложениями и "предложениями персонажа", вместе с доказательствами, что "предложения персонажа" следуют культурно приемлемым "интересам персонажа". Далее толпа других стейкхолдеров (а не только инженер по требованиям) утрамбовывают некультурного представителя в культурно-обусловленную позицию, а этот некультурный представитель имеет при этом выбор между полной потерей лица в серии публичных скандалов против изменения своей переговорной позиции. б) инженер по требованиям продолжает вопрошать этих лиц о требованиях, не публичить стоящие за этими требованиями интересы, не изобретать персонажа и не обращаться к культуре (т.е. "не думать за стейкхолдера -- не моделировать его, только внимать разинув рот!"), и получать затем скандал на собственную шкуру при провале проекта -- если, конечно, этот провал проекта хоть кого-нибудь волнует.

жалко, что вы не визуал (аудиал, видимо?). мне в этом посте не хватает пары диаграмм - безо всякой особенной нотации, просто сущности в виде квадратиков и отношения между сущностями в виде стрелочек - которые бы иллюстрировали отношения между архитектором, инженером по требованиям, собственно требованиями, стейкхолдерами, и прочими существительными, употреблёнными в посте. вот RUP был хорош [для меня, по крайней мере] тем, что не стеснялся рисовать диаграммы при каждом удобном случае.

Нет, я не аудиал :) Диаграммы не нарисовал только потому, что сейчас нет удобного инструментария для рисования (разве что ручка и бумажка). Но я займусь диаграммами, когда буду делать слайды к лекциям. Еще одно соображение: по-хорошему, все описанное представляет собой описание метода, и диаграммы тут должны быть из языка описания методов (SPEM или ISO 24744). Но эти языки в изобразительном плане убоги, поэтому "графический язык" (да и доработанную метамодель метода) для таких диаграмм еще нужно изобрести.

мне кажется, более формальная нотация нужна для верификации (вариантом которой является "не дать нарисовать неправильно") и, возможно, последующей генерации чего-либо downstream (кода, документации, whatever). а чтобы просто сделать проиллюстрировать мысль, достаточно квадратиков и стрелочек, мне кажется.

а инструментов для рисования квадратиков и стрелочек в сети полно, я вот недавно использовал yuml.me class diagrams чтобы пару графов нарисовать; быстро и удобно, хотя и не class diagrams вовсе.

Формальная нотация нужна как раз для правильного выражения мысли. Имеются же ввиду не художественные иллюстрации, а схемы? Если я излагаю метод, то все первичные половые признаки метода должны быть изложены -- и использование нотации (т.е. "схематизации по правилам") существенно этому способствует. Беда в том, что для методов такие нотации еще не устоялись, они только-только начинают разрабатываться.

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

Хорошая нотация как раз полезна и для обучения. Но это отдельная тема, в этом обсуждении мы увязнем -- я довольно долго разбирался с этими нотациями.