Доброго дня! Хотел бы узнать мнение сообщества на следующую тему:

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

Моё мнение почему это может быть полезно:
- Требование - постановка задачи. Если изначально отсутствуют критерии приёмки результата, то есть вероятность, что задача невыполнима. Следовательно ресурсы выделенные на эту задачу будут потрачены зря. Следовательно такой может привести проект к закрытию по выходу за рамки бюджета.
- Требование - в процессе разработки превращается в согласованное обязательство сторон (постановщика-исполнителя) о качестве результата работ. Если отсутствует способ определить качество выполнения работы - это может привести к снижению качества итогового результата. Что в итоге может привести к закрытию проекта по несоответствию целям.

Моё мнение почему может быть вредно:
- Есть некоторая вероятность, что требование может оказаться непроверяемым или невыполнимым на любой стадии жизненного цикла разрабатываемой системы. Тогда аналитик при разработке методов проверки должен быть достаточно компетентен в предметной области, чтобы предлагать такие методы. Это требует дополнительной квалификации и следовательно увеличения стоимости подготовки такого аналитика. Что в свою очередь сужает рынок поиска и может привести к закрытию проекта по выходу за сроки.

Моё мнение какие способы решения:
- В пару к аналитику давать предметника, способного указать проверяемость требований.
- Ввести понятие зрелости требований по их соответствию некоторым критериям качества. Например по INCOSE GfWR или ISO 29148 или внутренним стандартам предприятия др. Как следствие ввести понятие жизненного цикла требования со всеми последствиями. Например признать, что вся совокупность требований к системе - это её модель, и на основании оценки зрелости такой модели можно принимать решение о дальнейшей разработке и финансировании проекта.

Аналитик и предметник - всегда хорошая пара. Предметник при этом в проекте может быть и со стороны заказчика.

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

другое дело, что для доказательства тестируемости можно привлекать тест-инженера

я вчера отвечал на Хабре на похожие ранты про тестирование https://habr.com/ru/post/536454/

Я правильно понимаю, что в любом случае ДО того как требования уйдут в разработку мы должны убедиться в их верифицируемости и валидируемости ?

инженерия требований ПО говорит что да
agile в лице user stories говорит, что да
что скажет системная инженерия — надо разбираться
что скажет управление инновациями — тоже

Если учесть, что RE part of SE - то SE транзитивно говорит да )

А вот про управление инновациями - интересная тема. Но по-идее это не продуктовая разработка, а управление на некоторой стадии ЖЦ системы. Если посмотреть с этой точки зрения, то там скорее не требования, а гипотезы. И это ближе к исследовательской деятельности.

в том-то и дело, что RE и Software RE – это немного разны школы

4. Бизнес аналитик в ит) очень часто встречаю именно такую формулировку даже при курсах)

а чем хотите заниматься?

А нет ли случайно ссылок на  статью со сравнением ? Было бы интересно.

Наверное, как проектирование архитектуры. Может заниматься сам, если нет отдельного специалиста, но полную ответственность за качество этого блока (испытаний) нести не может / не должен

давайте на кейсах разберём

кейс

предприниматель задумал сделать умный гаджет/приложуху, чтобы повысить безопасность детей

аналитик делает требования, например, на уровне надсистемы:
1. «семья с ребёнком должна обеспечивать выживание ребёнка»
2. «семья с ребёнком должна обеспечивать сохранение здоровья ребёнка»

какие тесты придумаем?

Мой ответ - это не требования по определению. Это потребности.

почему?

Требование может быть признано требованием, если:
- его можно выполнить с учётом потребности заинтересованных сторон.
- его можно однозначно проверить.

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

проверку можно сделать с помощью анализа🤷‍♂