спасибо за идею!)
пошла смотреть)

Пожалуйста)))

Георгий Савельев рассказывает в статье, что такое Бизнес-требования и зачем они нужны https://systems.education/biz-req

Отличная статья, которая сконцентрирована на бизнес-требованиях, но затрагивает и другие виды требований. В статье производится не просто теоретический разбор терминов, но ещё есть и практические примеры.
В основном подход взят из BABOK, но упомянуты и другие стандарты и подходы.
Жду следующую часть!

Несколько комментариев:
1. Немного смущают "причастные лица", лично мне привычнее "заинтересованные лица/стороны".

2. Также немного смущает следующий момент:
> "Обычно требованиям стейкхолдеров сопутствуют дополнительные артефакты:
Карты стейкхолдеров (показывают, кто участвует в процессах)
Модели и другие описания процессов
Варианты использования (Use Cases)
Образцы данных, с которыми работают стейкхолдеры (помогают понять ситуацию и потребности стейкхолдеров)"

По-моему, кейсы как-то странно смотрятся в этом контексте. Возможно стоит их
упомянуть в следующем разделе про Требования к решению. В моей модели юз кейсы - это больше про проектирование. Ведь по сути это сценарий взаимодействия, которые можно дополнить ui прототипами, а про прототипы речь идёт ниже.

3. Раздел "Артефакты бизнес-анализа, сопровождающие бизнес-требования". Тут можно  упомянуть описания/модели бизнес-процессов. По-моему это важная часть контекста, но тут почему-то не упомянута.

4. Я не знаток скрама, но кажется можно провести параллель между Эпиками и Бизнес-требованиями.
> "Отсутствие понятия бизнес-требований — один из недостатков Scrum-подхода. "

Прочитав статью вспомнил что есть Agile Extension the BABOK v2 который я так и не прочитал. Надо исправиться.

а вот этот абзац, значит, не смущает? «Если внимательно посмотреть на требования к решению, можно увидеть, что, на самом деле, они перефразируют требования стейкхолдеров и мало что к ним добавляют. Поэтому, если не требуется отдельная формальная спецификация требований к решению (например, для заключения контракта), то разработка функциональных требований — бессмысленная трата времени.»

Нет, кстати вот с этим я вообще согласен)

В общем я не спорю что кейсы могут быть как дополнительный артефакт к сторям. Просто контекст в котором они упоминаются немного смущает

Всем привет!

Мне стало интересно, кто-нибудь использовал AsyncAPI на проектах? Или видел, как используют другие?

17 и 18 октября Сергей Медведев обучает работе с требованиями в Agile-проектах https://systems.education/product-owner

Что должно смущать. Аналитик это же "передаст“, ему заказчик сказал он программерам передал что надо сделать. Непыльная работёнка. Мозг можно не включать!

Послушаю :)

я считаю тут как в футболе - всегда виноват тот кто отдает пас

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

Если требование стейхолдера «Пользователь должен иметь возможность купить авиабилет», то ФТ «Сайт должен позволять купить билет» ничего нового не добавляет, речь об этом

Аналитик в РФ, который в теме ПО, это требование превратил бы в

Сайт должен позволять купить билет через:
1. Локульную GDS Sirena,
2. Минимум одну международную GDS из следующего списка: Amadeus, Sabre, Galileo
3. Через протокол NDC с авиакомпаниями S7, Аэрофлот

Звучит уже более осмысленно, правда? )

так это уже не ФТ

А какие?

это ограничения

Не знаю, что вы вкладываете в данном случае в этот термин. По смыслу это скорее некоторое решение, необходимое для выполнения бизнес-требования.

Требование от стейкхолдера в виде "Пользователь должен иметь возможность купить авиабилет" для этой предметной области - плохое (не говоря уже о том, что контекст требования мы не знаем в этом сферическом примере). Предположим, что речь идет о трэвел-агентстве, которое является аккредитованном в IATA агентом.

Тогда, требования от стэйкхолдера звучали бы, наверное, вот так:
1. Пользователь должен иметь возможность купить авиабилеты по РФ на любые локальные авиакомпании
2. Пользователь должен иметь возможность купить авиабилеты в/из России, а также международные билеты на основные международные авиакомпании
3. Как минимум на локальном Российском рынке сайт должен показаывать минимальную цену на билеты.

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

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

отличный пример, тогда получается, что приведённые выше каналы и протоколы — часть технического решения