Спасибо за вебинар👍Было очень полезно изменить взгляд на требования, увидеть в них информационные единицы (артефакт), управление которыми можно строить на основе подходов к управлению знаниями
17:40 "Я вижу в ТЗ, что пользователь должен. Так писать не нужно" Эти их рекомендации касаются только StR, SysR,SoftR. А в BRS например никаких таких ограничений нет, там про бизнес.
В целом надо понимать, что в международном подходе информационная, например, система, может состоять из ПО, оборудования, данных и процессов. А в советском подходе информационная система включала в себя обслуживающий персонал как составные части, поэтому можно было отдельно предъявлять требования к ним. С другой стороны, я считаю неконсистентной онтологию что Вигерса, что ISO: SysR - это требования к системе SoftR - это требования к ПО а BisR и StakeR - это почему-то не требования К бизнесу и не требования К стейкхолдерам, хотя это выглядит логичным и я это применяю. Тут почему-то перепутаны предмет требования (к чему оно) и его источник. Требования к бизнесу возникают у основателя, бизнес-владельца, внешних регуляторов и воплощаются в виде бизнес-модели организации. Например, в моём случае я как основатель выдвигаю ключевое функциональное требование к своему бизнесу, business capability «Организация должна проводить обучение практикам прикладного системного анализа в ИТ и проектирования информационных систем» Требования к стейхолдерам как участникам бизнеса могут возникать у ключевых функционеров бизнеса, которые определяют логику его работы. Например, директор по продажам (с помощью бизнес-аналитика или сам по себе) может выдвинуть требование к роли в бизнесе, совмещённое с ограничением-атрибутом качества - «Менеджер по продажам должен подготовить коммерческое предложение для клиентов после получения заявки в течение 3 рабочих дней в 80% случаев».
> Эти их рекомендации касаются только StR, SysR,SoftR. А в BRS например никаких таких ограничений нет, там про бизнес. Да, все так. > А в советском подходе информационная система включала в себя обслуживающий персонал как составные части, поэтому можно было отдельно предъявлять требования к ним. Да, только автоматизированная система. Если я правильно помню, в 34 ГОСТе не было такого понятия, как ИС, но мне оно кажется удобным, чтобы обозначать системы, первая задача которых именно обрабатывать информация, а не автоматизировать реальное производство. Но это, конечно, моя самодеятельность, потому что по ГОСТу объектом автоматизации может быть и то, что сейчас мы бы назвали бизнес-процессом.
18:34 «требование может быть в виде диаграммки, в виде прототипа» - но это же неправда, в тексте и на экране прямо написано, что это именно лексическая конструкция
Да, здесь я ошибся, спасибо, что подметил. Другие представления требований это уже трассируемые к нему артефакты, а у требования текстовая форма записи: a requirement can be written in the form of a natural language or some other form of language
36:35 "если будете писать документы, то для каждого из этих вы напишете свои документики" так до этого же шла речь о том, что в стандарте произошёл якобы переход от документарного подхода к современному, где требования не обязаны быть в документе? просто у нас есть массив требований в системе их учёта, как-то выделенный в какую-то конфигурационную единицу, например, с привязкой к релизу или версии
15:46 "инженеров по требованиям, что в россии обычно называется системный аналитик" - это ситуация 10-летней давности сейчас как можно видеть по вакансиям, СА в россии - это скорее проектировщик интеграций, требования уходят на второй-третий план, особенно во внутренней и продуктовой разработке
Да, все так, системные аналитики всё больше движутся в сторону младших проектировщиков. Однако, и по IEEE-стандарту, такое проектирование интеграций можно отнести к инженерии требований тоже.
непонятно, как именно такой явно каскадный и уровневый подход ложится в agile и продуктовую разработку, например, в том же JetBrains кажется, что для какого-нибудь PyCharm уровень BRS мало применим, а остальные уровни плохо бьются с культурой product discovery, гипотезы, CJM, и т.д.
Никак не объяснено, почему в качестве основного термина для обсуждения выбрано «управление требованиями», а не «инженерия требований». Поскольку основная часть посвящена разработке требований, то странно всё вместе называть управлением. Сравните - проектирование автомобиля и управление автомобилем. Управление подразумевает управляющие воздействия на что-то, что уже существует. Вот мой рассказ на AD-2012 про это, жалко, что новое поколение не воспринимает аргументы и наработки предыдущего:
Спасибо за вебинар👍Было очень полезно изменить взгляд на требования, увидеть в них информационные единицы (артефакт), управление которыми можно строить на основе подходов к управлению знаниями
Шикарный вебинар, огромное спасибо!
17:40 "Я вижу в ТЗ, что пользователь должен. Так писать не нужно"
Эти их рекомендации касаются только StR, SysR,SoftR. А в BRS например никаких таких ограничений нет, там про бизнес.
В целом надо понимать, что в международном подходе информационная, например, система, может состоять из ПО, оборудования, данных и процессов.
А в советском подходе информационная система включала в себя обслуживающий персонал как составные части, поэтому можно было отдельно предъявлять требования к ним.
С другой стороны, я считаю неконсистентной онтологию что Вигерса, что ISO:
SysR - это требования к системе
SoftR - это требования к ПО
а BisR и StakeR - это почему-то не требования К бизнесу и не требования К стейкхолдерам, хотя это выглядит логичным и я это применяю.
Тут почему-то перепутаны предмет требования (к чему оно) и его источник.
Требования к бизнесу возникают у основателя, бизнес-владельца, внешних регуляторов и воплощаются в виде бизнес-модели организации.
Например, в моём случае я как основатель выдвигаю ключевое функциональное требование к своему бизнесу, business capability «Организация должна проводить обучение практикам прикладного системного анализа в ИТ и проектирования информационных систем»
Требования к стейхолдерам как участникам бизнеса могут возникать у ключевых функционеров бизнеса, которые определяют логику его работы. Например, директор по продажам (с помощью бизнес-аналитика или сам по себе) может выдвинуть требование к роли в бизнесе, совмещённое с ограничением-атрибутом качества - «Менеджер по продажам должен подготовить коммерческое предложение для клиентов после получения заявки в течение 3 рабочих дней в 80% случаев».
> Эти их рекомендации касаются только StR, SysR,SoftR. А в BRS например никаких таких ограничений нет, там про бизнес.
Да, все так.
> А в советском подходе информационная система включала в себя обслуживающий персонал как составные части, поэтому можно было отдельно предъявлять требования к ним.
Да, только автоматизированная система. Если я правильно помню, в 34 ГОСТе не было такого понятия, как ИС, но мне оно кажется удобным, чтобы обозначать системы, первая задача которых именно обрабатывать информация, а не автоматизировать реальное производство. Но это, конечно, моя самодеятельность, потому что по ГОСТу объектом автоматизации может быть и то, что сейчас мы бы назвали бизнес-процессом.
18:34 «требование может быть в виде диаграммки, в виде прототипа» - но это же неправда, в тексте и на экране прямо написано, что это именно лексическая конструкция
Да, здесь я ошибся, спасибо, что подметил. Другие представления требований это уже трассируемые к нему артефакты, а у требования текстовая форма записи: a requirement can be written in the form of a natural language or some other form of language
36:35 "если будете писать документы, то для каждого из этих вы напишете свои документики"
так до этого же шла речь о том, что в стандарте произошёл якобы переход от документарного подхода к современному, где требования не обязаны быть в документе?
просто у нас есть массив требований в системе их учёта, как-то выделенный в какую-то конфигурационную единицу, например, с привязкой к релизу или версии
почему тогда такое место в стандарте занимают именно документы?
Видимо, потому что документы остается самым частым способом представления документов, как мне кажется.
Денис, можете ли вы рассказать чуть подробнее об учете требований с привязкой к релизу или версии, пожалуйста?
Как это сделать??
@@ВалерияПирог-е1и через атрибуты и связи в любой современной системе учёта требований - Confluence, Notion, Coda и т.д.
15:46 "инженеров по требованиям, что в россии обычно называется системный аналитик" - это ситуация 10-летней давности
сейчас как можно видеть по вакансиям, СА в россии - это скорее проектировщик интеграций, требования уходят на второй-третий план, особенно во внутренней и продуктовой разработке
Да, все так, системные аналитики всё больше движутся в сторону младших проектировщиков. Однако, и по IEEE-стандарту, такое проектирование интеграций можно отнести к инженерии требований тоже.
непонятно, как именно такой явно каскадный и уровневый подход ложится в agile и продуктовую разработку, например, в том же JetBrains
кажется, что для какого-нибудь PyCharm уровень BRS мало применим, а остальные уровни плохо бьются с культурой product discovery, гипотезы, CJM, и т.д.
Никак не объяснено, почему в качестве основного термина для обсуждения выбрано «управление требованиями», а не «инженерия требований».
Поскольку основная часть посвящена разработке требований, то странно всё вместе называть управлением.
Сравните - проектирование автомобиля и управление автомобилем.
Управление подразумевает управляющие воздействия на что-то, что уже существует.
Вот мой рассказ на AD-2012 про это, жалко, что новое поколение не воспринимает аргументы и наработки предыдущего:
ua-cam.com/video/boVN9upicGQ/v-deo.html
Ссылка с первого слайда:
ua-cam.com/play/PLy1tonXI6g95amA5dE1hsDSB0j5a9JpBV.html