Константин Валеев. Управление требованиями по ISO/IEEE-29148: обзор действующего стандарта

[@Ирина-м3и5н]

Спасибо за вебинар👍Было очень полезно изменить взгляд на требования, увидеть в них информационные единицы (артефакт), управление которыми можно строить на основе подходов к управлению знаниями

[@imNirs]

Шикарный вебинар, огромное спасибо!

[@DenisBeskov]

17:40 "Я вижу в ТЗ, что пользователь должен. Так писать не нужно" Эти их рекомендации касаются только StR, SysR,SoftR. А в BRS например никаких таких ограничений нет, там про бизнес.

[@DenisBeskov]

В целом надо понимать, что в международном подходе информационная, например, система, может состоять из ПО, оборудования, данных и процессов. А в советском подходе информационная система включала в себя обслуживающий персонал как составные части, поэтому можно было отдельно предъявлять требования к ним. С другой стороны, я считаю неконсистентной онтологию что Вигерса, что ISO: SysR - это требования к системе SoftR - это требования к ПО а BisR и StakeR - это почему-то не требования К бизнесу и не требования К стейкхолдерам, хотя это выглядит логичным и я это применяю. Тут почему-то перепутаны предмет требования (к чему оно) и его источник. Требования к бизнесу возникают у основателя, бизнес-владельца, внешних регуляторов и воплощаются в виде бизнес-модели организации. Например, в моём случае я как основатель выдвигаю ключевое функциональное требование к своему бизнесу, business capability «Организация должна проводить обучение практикам прикладного системного анализа в ИТ и проектирования информационных систем» Требования к стейхолдерам как участникам бизнеса могут возникать у ключевых функционеров бизнеса, которые определяют логику его работы. Например, директор по продажам (с помощью бизнес-аналитика или сам по себе) может выдвинуть требование к роли в бизнесе, совмещённое с ограничением-атрибутом качества - «Менеджер по продажам должен подготовить коммерческое предложение для клиентов после получения заявки в течение 3 рабочих дней в 80% случаев».

[@konstantinvaleev6561]

> Эти их рекомендации касаются только StR, SysR,SoftR. А в BRS например никаких таких ограничений нет, там про бизнес. Да, все так. > А в советском подходе информационная система включала в себя обслуживающий персонал как составные части, поэтому можно было отдельно предъявлять требования к ним. Да, только автоматизированная система. Если я правильно помню, в 34 ГОСТе не было такого понятия, как ИС, но мне оно кажется удобным, чтобы обозначать системы, первая задача которых именно обрабатывать информация, а не автоматизировать реальное производство. Но это, конечно, моя самодеятельность, потому что по ГОСТу объектом автоматизации может быть и то, что сейчас мы бы назвали бизнес-процессом.

[@DenisBeskov]

непонятно, как именно такой явно каскадный и уровневый подход ложится в agile и продуктовую разработку, например, в том же JetBrains кажется, что для какого-нибудь PyCharm уровень BRS мало применим, а остальные уровни плохо бьются с культурой product discovery, гипотезы, CJM, и т.д.

[@DenisBeskov]

18:34 «требование может быть в виде диаграммки, в виде прототипа» - но это же неправда, в тексте и на экране прямо написано, что это именно лексическая конструкция

[@konstantinvaleev6561]

Да, здесь я ошибся, спасибо, что подметил. Другие представления требований это уже трассируемые к нему артефакты, а у требования текстовая форма записи: a requirement can be written in the form of a natural language or some other form of language

[@DenisBeskov]

Никак не объяснено, почему в качестве основного термина для обсуждения выбрано «управление требованиями», а не «инженерия требований». Поскольку основная часть посвящена разработке требований, то странно всё вместе называть управлением. Сравните - проектирование автомобиля и управление автомобилем. Управление подразумевает управляющие воздействия на что-то, что уже существует. Вот мой рассказ на AD-2012 про это, жалко, что новое поколение не воспринимает аргументы и наработки предыдущего:

[@DenisBeskov]

kzbin.info/www/bejne/mKC5f2yrpc6WfbM

[@DenisBeskov]

36:35 "если будете писать документы, то для каждого из этих вы напишете свои документики" так до этого же шла речь о том, что в стандарте произошёл якобы переход от документарного подхода к современному, где требования не обязаны быть в документе? просто у нас есть массив требований в системе их учёта, как-то выделенный в какую-то конфигурационную единицу, например, с привязкой к релизу или версии

[@DenisBeskov]

почему тогда такое место в стандарте занимают именно документы?

[@konstantinvaleev6561]

Видимо, потому что документы остается самым частым способом представления документов, как мне кажется.

[@ВалерияПирог-е1и]

Денис, можете ли вы рассказать чуть подробнее об учете требований с привязкой к релизу или версии, пожалуйста? Как это сделать??

[@DenisBeskov]

@@ВалерияПирог-е1и через атрибуты и связи в любой современной системе учёта требований - Confluence, Notion, Coda и т.д.

[@DenisBeskov]

15:46 "инженеров по требованиям, что в россии обычно называется системный аналитик" - это ситуация 10-летней давности сейчас как можно видеть по вакансиям, СА в россии - это скорее проектировщик интеграций, требования уходят на второй-третий план, особенно во внутренней и продуктовой разработке

[@konstantinvaleev6561]

Да, все так, системные аналитики всё больше движутся в сторону младших проектировщиков. Однако, и по IEEE-стандарту, такое проектирование интеграций можно отнести к инженерии требований тоже.

[@DenisBeskov]

Ссылка с первого слайда:

[@DenisBeskov]

kzbin.info/aero/PLy1tonXI6g95amA5dE1hsDSB0j5a9JpBV