К вопросу, что мы делаем с требованиями. Я тут написал — "собираем", на что получил справедливое возражение, что нечего там собирать, нет их у стейкхолдеров, по крайне мере обоснованных и четко сформулированных. Не растут требования, как грибы — только возьми и собери.

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

Ещё вариант: извлекаем. Это скорее про документы, где есть какие-то тексты про предметку и процессы, и в которых, при желании, требования можно увидеть.

Но, давайте будем честны: мы требования просто придумываем! Сами, или, если повезло — совместно со стейкхолдерами.

Можно этот процесс маскировать словом "разработка" требований (был и такой вариант). Или, чтобы совсем красиво звучало: co-development, или совсем по-модному co-design. И придумал это не Пол Ральф со своими статьями про контрпродуктивность идеи "сбора требований", а задолго до него.

Например, Клаус Пол (Klaus Pohl, один из основателей сертификации IREB) ещё в 2007 описал метод COSMOD-RE, где честно говорится: требования и архитектура системы разрабатываются в едином процессе co-development'а. И шаги "разработка целей и сценариев" и "разработка архитектуры" там на одном уровне (на самом деле это единый процесс).

Метод, по-видимому, плотно забыт, описания его еле гуглятся, а текстов статей и докладов нет в открытом доступе. Но можно посмотреть на несколько картинок.

COSMOD-RE задает 4 уровня:
1. Системы в целом;
2. Функциональной декомпозиции системы (разбивку на компоненты);
3. Распределение софтверных компонент по железу;
4. Уровень развертывания.

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

Любопытно (и полезно!), что здесь выделено 4 уровня, причем последние 2 захватывают хардвер. Аналитики же, даже системные, обычно в своих абстракциях далеки от размышлений — на чем всё это будет крутиться.

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